Open Stack

On 18/09/17 09:37 -0600, 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.


Hey James,

sorry for getting back to this thread this late!

I like the approach and I think it makes sense for us to go down this path. As
far as my research on tripleo+kubernetes goes, I think this plan aligns quite
well with what I've been doing so far.

That said, I need to dive more into how `config download` works and start using
it for future demos and development.

Flavio

--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170925/6dd030af/attachment.sig>