Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move TOSCA nodes deployment at WF level #48

Open
lorenzo-biava opened this issue May 31, 2016 · 1 comment
Open

Move TOSCA nodes deployment at WF level #48

lorenzo-biava opened this issue May 31, 2016 · 1 comment

Comments

@lorenzo-biava
Copy link
Contributor

lorenzo-biava commented May 31, 2016

Currently all TOSCA nodes are deployed in a single WF task (via code, for simplicity).
To support more complex and bigger templates, that task should be done at the WF level (also enabling single node failure handling and retrying).

This enhancement is also related to the Parameter Sweep feature (which would generate very large templates - ~10k nodes).

@lorenzo-biava
Copy link
Contributor Author

lorenzo-biava commented Jun 1, 2016

  • First improvement might be: cycle through the Chronos jobs and create one for each jBPM task.
  • Then we might think to launch every node creation/wait-for-completion independently (see Multi-instance sub-process in jBPM)

lorenzo-biava added a commit that referenced this issue Jun 8, 2016
- Workflows have been improved using DeploymentMessage as the main
DeploymentService interface method's parameter in order to allow for
greater customization of the Deployment (i.e. chosen CloudProvider,
OneData settings, etc).

- Workflows now support Deploy/Poll/Undeploy task iteration to allow the
underlying command to work on a subset of TOSCA nodes (i.e. creating one
Job at a time to avoid transaction timeout).

Related to #48, #51, #53, #55
Fixes #44
lorenzo-biava added a commit that referenced this issue Jun 9, 2016
Chronos job are created/polled/deleted in chuncks instead of one for
each WF task invocation to improve performance (to avoid
serialization/deserialization overhead).

The `orchestrator.chronos.jobChunkSize` property allows customization of
this behavior.

See #48
@lorenzo-biava lorenzo-biava added this to the 2nd release milestone Jun 16, 2016
@alberto-brigandi alberto-brigandi modified the milestones: 1.3, Next Apr 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants