On Thu, Jul 20, 2017 at 10:06:00PM -0400, James Slagle wrote: > On Thu, Jul 20, 2017 at 9:52 PM, James Slagle <[email protected]> wrote: > > On Thu, Jul 20, 2017 at 9:04 PM, Paul Belanger <[email protected]> > > 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. > Right, that's what I was trying to say. I believe you have some ansible logic within your heat templates today. As I understand it, dynamically generated. I would think first moving that logic outside of heat into stand alone playbooks would be a good first step. Then you wouldn't need to write the tool from above right?
I'm not too familiar with all the lays in tripleo, so it is possible I am wrong. > 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. > Are you running a single ansible-playbook command for each task or multiple ansible-playbook runs? > -- > -- James Slagle > -- > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
