<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 1:21 AM, James Slagle <span dir="ltr"><<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Following up on the previous thread:<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2017-July/119405.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>July/119405.html</a><br>
<br>
I wanted to share some work I did around the prototype I mentioned<br>
there. I spent a couple days exploring this idea. I came up with a<br>
Python script that when run against an in progress Heat stack, will<br>
pull all the server and deployment metadata out of Heat and generate<br>
ansible playbooks/tasks from the deployments.<br>
<br>
Here's the code:<br>
<a href="https://github.com/slagle/pump" rel="noreferrer" target="_blank">https://github.com/slagle/pump</a><br>
<br>
And an example of what gets generated:<br>
<a href="https://gist.github.com/slagle/433ea1bdca7e026ce8ab2c46f4d716a8" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>slagle/<wbr>433ea1bdca7e026ce8ab2c46f4d716<wbr>a8</a><br>
<br>
If you're interested in any more detail, let me know.<br>
<br>
It signals the stack to completion with a dummy "ok" signal so that<br>
the stack will complete. You can then use ansible-playbook to apply<br>
the actual deloyments (in the expected order, respecting the steps<br>
across all roles, and in parallel across all the roles).<br>
<br>
Effectively, this treats Heat as nothing but a yaml cruncher. When<br>
using it with deployed-server, Heat doesn't actually change anything<br>
on an overcloud node, you're only using it to generate ansible.<br></blockquote><div><br></div><div><div><br></div><div>Hi James, </div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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?</div><div><br></div><div>thanks, marios</div><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/tripleo-pike-updates-upgrades">https://etherpad.openstack.org/p/tripleo-pike-updates-upgrades</a></div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Honestly, I think I will prefer the longer term approach of using<br>
stack outputs. Although, I am not sure of the end goal of that work<br>
and if it is the same as this prototype.<br>
<br>
And some of what I've done may be useful with that approach as well:<br>
<a href="https://review.openstack.org/#/c/485303/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/485303/</a><br>
<br>
However, I found this prototype interesting and worth exploring for a<br>
couple of reasons:<br>
<br>
Regardless of the approach we take, I wanted to explore what an end<br>
result might look like. Personally, this illustrates what I kind of<br>
had in mind for an "end goal".<br>
<br>
I also wanted to see if this was at all feasible. I envisioned some<br>
hurdles, such as deployments depending on output values of previous<br>
deployments, but we actually only do that in 1 place in<br>
tripleo-heat-templates, and I was able to workaround that. In the end<br>
I used it to deploy an all in one overcloud equivalent to our<br>
multinode CI job, so I believe it's feasible.<br>
<br>
It meets most of the requirements we're looking to get out of ansible.<br>
You can (re)apply just a single deployment, or a given deployment<br>
across all ResourceGroup members, or all deployments for a given<br>
server(s), it's easy to see what failed and for what servers, etc.<br>
<br>
FInally, It's something we could deliver  without much (any?) change<br>
in tripleo-heat-templates. Although I'm not trying to say it'd be a<br>
small amount of work to even do that, as this is a very rough<br>
prototype.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
--<br>
-- James Slagle<br>
--<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>