Open Stack

Was there any discussion at the PTG on how the newly released AWX[1] 
will affect tripleo/ansible (will it?) or ara or such? Thoughts there?

[1] https://github.com/ansible/awx

James Slagle wrote:
> 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
>