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?
Basically, we do this for zuulv2.5 today in openstack-infra (dynamically generate playbooks at run-time) and it is a large amount of work to debug issues. In our case, we did it to quickly migrate from jenkins to ansible (since zuulv3 completely fixes this with native playbooks) and I wouldn't recommend it to operators to do. Not fun. > And some of what I've done may be useful with that approach as well: > https://review.openstack.org/#/c/485303/ > > However, I found this prototype interesting and worth exploring for a > couple of reasons: > > Regardless of the approach we take, I wanted to explore what an end > result might look like. Personally, this illustrates what I kind of > had in mind for an "end goal". > > I also wanted to see if this was at all feasible. I envisioned some > hurdles, such as deployments depending on output values of previous > deployments, but we actually only do that in 1 place in > tripleo-heat-templates, and I was able to workaround that. In the end > I used it to deploy an all in one overcloud equivalent to our > multinode CI job, so I believe it's feasible. > > It meets most of the requirements we're looking to get out of ansible. > You can (re)apply just a single deployment, or a given deployment > across all ResourceGroup members, or all deployments for a given > server(s), it's easy to see what failed and for what servers, etc. > > FInally, It's something we could deliver without much (any?) change > in tripleo-heat-templates. Although I'm not trying to say it'd be a > small amount of work to even do that, as this is a very rough > prototype. > > -- > -- 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 __________________________________________________________________________ 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
