On 11/2/18 2:39 PM, Dan Prince wrote: > I pushed a patch[1] to update our containerized deployment > architecture docs yesterday. There are 2 new fairly useful sections we > can leverage with TripleO's stepwise deployment. They appear to be > used somewhat sparingly so I wanted to get the word out.
Good thing, it's important to highlight this feature and explain how it works, big thumb up Dan! > > The first is 'deploy_steps_tasks' which gives you a means to run > Ansible snippets on each node/role in a stepwise fashion during > deployment. Previously it was only possible to execute puppet or > docker commands where as now that we have deploy_steps_tasks we can > execute ad-hoc ansible in the same manner. I'm wondering if such a thing could be used for the "inflight validations" - i.e. a step to validate a service/container is working as expected once it's deployed, in order to get early failure. For instance, we deploy a rabbitmq container, and right after it's deployed, we'd like to ensure it's actually running and works as expected before going forward in the deploy. Care to have a look at that spec[1] and see if, instead of adding a new "validation_tasks" entry, we could "just" use the "deploy_steps_tasks" with the right step number? That would be really, really cool, and will probably avoid a lot of code in the end :). Thank you! C. [1] https://review.openstack.org/#/c/602007/ > > The second is 'external_deploy_tasks' which allows you to use run > Ansible snippets on the Undercloud during stepwise deployment. This is > probably most useful for driving an external installer but might also > help with some complex tasks that need to originate from a single > Ansible client. > > The only downside I see to these approaches is that both appear to be > implemented with Ansible's default linear strategy. I saw shardy's > comment here [2] that the :free strategy does not yet apparently work > with the any_errors_fatal option. Perhaps we can reach out to someone > in the Ansible community in this regard to improve running these > things in parallel like TripleO used to work with Heat agents. > > This is also how host_prep_tasks is implemented which BTW we should > now get rid of as a duplicate architectural step since we have > deploy_steps_tasks anyway. > > [1] https://review.openstack.org/#/c/614822/ > [2] > http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/common/deploy-steps.j2#n554 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cédric Jeanneret Software Engineer DFG:DF
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev