Open Stack

On Fri, Jul 21, 2017 at 1:21 AM, James Slagle <james.slagle at gmail.com>
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.
>


Hi James,

FYI this actually describes the current plan for Pike minor update [1] -
the idea is to use the "openstack overcloud config download " (matbu++) to
write the playbooks for each node from the deployed stack outputs. The
minor update playbook(s) itself will be generated from new 'update_tasks'
added to each of the service manifests (akin to the current upgrade_tasks).
The plan is to disable the actual service config deployment steps so that
we just get the stack outputs for the playbook generation.

The effort is lead by shardy and he has posted reviews/comments on the
etherpad @ [1] FYI (I know he is away this week so may not respond ++ I was
struck by the similarity between what you described above and the consensus
we seemed to reach towards the end of the week about the minor update plan,
so I thought you and others may be interested to hear it).

Your review @ /#/c/485303/ is slightly different in that it doesn't disable
the deployment/postdeploy steps but signals completion to Heat. Haven't
checked that review in  detail but first concern is can/do you catch it in
time... I mean you start the heat stack update and have to immediately call
the openstack overcloud signal , if I understood correctly?

thanks, marios

[1] https://etherpad.openstack.org/p/tripleo-pike-updates-upgrades



>
> 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.
>
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170724/9570bfd2/attachment.html>