On Thu, Jul 20, 2017 at 9:52 PM, James Slagle <james.sla...@gmail.com> wrote: > On Thu, Jul 20, 2017 at 9:04 PM, Paul Belanger <pabelan...@redhat.com> wrote: >> On Thu, Jul 20, 2017 at 06:21:22PM -0400, James Slagle wrote: >>> Following up on the previous thread: >>> http://lists.openstack.org/pipermail/openstack-dev/2017-July/119405.html >>> >>> I wanted to share some work I did around the prototype I mentioned >>> there. I spent a couple days exploring this idea. I came up with a >>> Python script that when run against an in progress Heat stack, will >>> pull all the server and deployment metadata out of Heat and generate >>> ansible playbooks/tasks from the deployments. >>> >>> Here's the code: >>> https://github.com/slagle/pump >>> >>> And an example of what gets generated: >>> https://gist.github.com/slagle/433ea1bdca7e026ce8ab2c46f4d716a8 >>> >>> If you're interested in any more detail, let me know. >>> >>> It signals the stack to completion with a dummy "ok" signal so that >>> the stack will complete. You can then use ansible-playbook to apply >>> the actual deloyments (in the expected order, respecting the steps >>> across all roles, and in parallel across all the roles). >>> >>> Effectively, this treats Heat as nothing but a yaml cruncher. When >>> using it with deployed-server, Heat doesn't actually change anything >>> on an overcloud node, you're only using it to generate ansible. >>> >>> Honestly, I think I will prefer the longer term approach of using >>> stack outputs. Although, I am not sure of the end goal of that work >>> and if it is the same as this prototype. >>> >> Sorry if this hasn't been asked before but why don't you removed all of your >> ansible-playbook logic out of heat and write them directly as native >> playbooks / >> roles? Then instead of having a tool that reads heat to then generate the >> playbooks / roles, you update heat just to directly call the playbooks? Any >> dynamic information about be stored in the inventory or using the >> --extra-vars >> on the CLI? > > We must maintain backwards compatibility with our existing Heat based > interfaces (cli, api, templates). While that could probably be done > with the approach you mention, it feels like it would be much more > difficult to do so in that you'd need to effectively add back on the > compatibility layer once the new pristine native ansible > playbooks/roles were written. And it seems like it would be quite a > lot of heat template work to translate existing interfaces to call > into the new playbooks. > > Even then, any new playbooks written from scratch would have to be > flexible enough to accommodate the old interfaces. On the surface, it > feels like you may end up sacrificing a lot of your goals in your > playbooks so you can maintain backwards compatibility anyways. > > The existing interface must be the first class citizen. We can't break > those contracts, so we need ways to quickly iterate towards ansible. > Writing all new native playbooks sounds like just writing a new > OpenStack installer to me, and then making Heat call that so that it's > backwards compatible. > > The focus on the interface flips that around so that you use existing > systems and iterate them towards the end goal. Just my POV. > > FYI, there are other ongoing solutions as well such as existing > ansible tasks directly in the templates today. These are much easier > to reason about when it comes to generating the roles and playbooks, > because it is direct Ansible syntax in the templates, so it's easier > to see the origin of tasks and make changes.
I also wanted to mention that the Ansible tasks in the templates today could be included with Heat's get_file function. In which case, as a template developer you basically are writing a native Ansible tasks file that could be included in an Ansible role. The generation would still come into play when combining the tasks into the role/playbook that is actually applied to a given server, since that is all dynamic based on user input. -- -- 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