On Wednesday at the PTG, TripleO held a session around our current use of Ansible and how to move forward. I'll summarize the results of the session. Feel free to add anything I forgot and provide any feedback or questions.
We discussed the existing uses of Ansible in TripleO and how they differ in terms of what they do and how they interact with Ansible. I covered this in a previous email[1], so I'll skip over summarizing those points again. I explained a bit about the "openstack overcloud config download" approach implemented in Pike by the upgrades squad. This method no-op's out the deployment steps during the actual Heat stack-update, then uses the cli to query stack outputs to create actual Ansible playbooks from those output values. The Undercloud is then used as the Ansible runner to apply the playbooks to each Overcloud node. I created a sequence diagram for this method and explained how it would also work for initial stack deployment[2]: https://slagle.fedorapeople.org/tripleo-ansible-arch.png The high level proposal was to move in a direction where we'd use the config download method for all Heat driven stack operations (stack-create and stack-update). We highlighted and discussed several key points about the method shown in the diagram: - The entire sequence and flow is driven via Mistral on the Undercloud by default. This preserves the API layer and provides a clean reusable interface for the CLI and GUI. - It would still be possible to run ansible-playbook directly for various use cases (dev/test/POC/demos). This preserves the quick iteration via Ansible that is often desired. - The remaining SoftwareDeployment resources in tripleo-heat-templates need to be supported by config download so that the entire configuration can be driven with Ansible, not just the deployment steps. The success criteria for this point would be to illustrate using an image that does not contain a running os-collect-config. - The ceph-ansible implementation done in Pike could be reworked to use this model. "config download" could generate playbooks that have hooks for calling external playbooks, or those hooks could be represented in the templates directly. The result would be the same either way though in that Heat would no longer be triggering a separate Mistral workflow just for ceph-ansible. - We will need some centralized log storage for the ansible-playbook results and should consider using ARA. As it would be a lot of work to eventually make this method the default, I don't expect or plan that we will complete all this work in Queens. We can however start moving in this direction. Specifically, I hope to soon add support to config download for the rest of the SoftwareDeployment resources in tripleo-heat-templates as that will greatly simplify the undercloud container installer. Doing so will illustrate using the ephemeral heat-all process as simply a means for generating ansible playbooks. I plan to create blueprints this week for Queens and beyond. If you're interested in this work, please let me know. I'm open to the idea of creating an official squad for this work, but I'm not sure if it's needed or not. As not everyone was able to attend the PTG, please do provide feedback about this plan as it should still be considered open for discussion. [1] http://lists.openstack.org/pipermail/openstack-dev/2017-July/119405.html [2] https://slagle.fedorapeople.org/tripleo-ansible-arch.png -- -- James Slagle -- __________________________________________________________________________ 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
