The simulatir tool can be used either to virtually
run the deployment to find out the task run order
or to plot the entire graph or its subset.
> Run deployment from the YAML dumped by Astute
astute-simulator -y /path/to/yaml/file.yaml
> Run deployments with task failure emulation
astute-simulator -y /path/to/yaml/file.yaml -f ntp-client/2,heat-db/1 -P
> Using node and task name filters
astute-simulator -y /path/to/yaml/file.yaml -g openstack -G '^2$' -p
Related-bug: #1569839
Change-Id: I6f583347e2f039a470410900c38d7a1d70151b56
Several changes:
- support fault tolerance group;
- support internal stop deployment instead of raise in
case of error;
- do not show last run summary debug report from mcollective;
- fix support of detecting offline nodes before run deployment;
- support fail on error behavior.
Support fault tolerance group
Nailgun send fault tolerance group which inform Astute about
available number of error nodes in this deployment and importance
of every node in this task.
If number of error exceeds number of available errors, deployment
will stop.
Support internal stop deployment instead of raise in case of error
Before this change Astute is end processing, marks all nodes
as error and do not waiting of puppet process on nodes.
Now we use same way that used in case of stop deployment.
Mark failed nodes as error, another nodes as skipped(stopped),
ready nodes as ready. Also Astute will wait before current
tasks end.
Do not show last run summary debug report from mcollective
For now moment it not so useful, but quickly filled log file
and difficult debug process
Fix support of detecting offline nodes before run deployment
Astute gets response from mcollective to detect node availability.
If node do not respond, it will mark as failed. It also support
fault tollerance mechanism
Support fail on error behavior
From this moment task which setup fail_on_error if false,
task marks as skipped instead of failed in case of error.
Change-Id: Ica2a4ae64b4dfa4f7fccfbc95108d1412c40dc3f
Closes-Bug: #1435610
removed automatic retries, they can cause duplication of tarballs
even when snapshot can not be generated in given timeout
Change-Id: I4c5fec5d72d2ed76528d1b03d878ca0572e012f2
Closes-Bug: 1414059
Andreas Jaeger