Open Stack

On Thu, Jul 20, 2017 at 10:06:00PM -0400, James Slagle wrote:
> On Thu, Jul 20, 2017 at 9:52 PM, James Slagle <james.slagle at gmail.com> wrote:
> > On Thu, Jul 20, 2017 at 9:04 PM, Paul Belanger <pabelanger at 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.
> 
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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev