<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský <span dir="ltr"><<a href="mailto:jistr@redhat.com" target="_blank">jistr@redhat.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"><div class="gmail-HOEnZb"><div class="gmail-h5">On 21.9.2017 12:31, Giulio Fidente wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 09/20/2017 07:36 PM, James Slagle wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente <<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 09/18/2017 05:37 PM, James Slagle wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- The entire sequence and flow is driven via Mistral on the Undercloud<br>
by default. This preserves the API layer and provides a clean reusable<br>
interface for the CLI and GUI.<br>
</blockquote>
<br>
I think it's worth saying that we want to move the deployment steps out<br>
of heat and in ansible, not in mistral so that mistral will run the<br>
workflow only once and let ansible go through the steps<br>
<br>
I think having the steps in mistral would be a nice option to be able to<br>
rerun easily a particular deployment step from the GUI, versus having<br>
them in ansible which is instead a better option for CLI users ... but<br>
it looks like having them in ansible is the only option which permits us<br>
to reuse the same code to deploy an undercloud because having the steps<br>
in mistral would require the undercloud installation itself to depend on<br>
mistral which we don't want to<br>
<br>
James, Dan, please comment on the above if I am wrong<br>
</blockquote>
<br>
That's correct. We don't want to require Mistral to install the<br>
Undercloud. However, I don't think that necessarily means it has to be<br>
a single call to ansible-playbook. We could have multiple invocations<br>
of ansible-playbook. Both Mistral and CLI code for installing the<br>
undercloud could handle that easily.<br>
<br>
You wouldn't be able to interleave an external playbook among the<br>
deploy steps however. That would have to be done under a single call<br>
to ansible-playbook (at least how that is written now). We could<br>
however have hooks that could serve as integration points to call<br>
external playbooks after each step.<br>
</blockquote>
<br>
the benefits of driving the steps from mistral are that then we could<br>
also interleave the deployment steps and we won't need the<br>
ansible-playbook hook for the "external" services:<br>
<br>
1) collect the ansible tasks *and* the workflow_tasks (per step) from heat<br>
<br>
2) launch the stepN deployment workflow (ansible-playbook)<br>
<br>
3) execute any workflow_task defined for stepN (like ceph-ansible playbook)<br>
<br>
4) repeat 2 and 3 for stepN+1<br>
<br>
I think this would also provide a nice interface for the UI ... but then<br>
we'd need mistral to be able to deploy the undercloud<br>
<br></blockquote></div></div></blockquote><div><br></div><div><br></div><div><div>Why not launch the _single_  deploy_steps playbook (so we have when/conditionals with step numbers), passing in the step you want to have executed (we can pass this in as a parameter to the mistral workflow and pass through to the ansible-playbook invocation?), otherwise execute all the steps. In either case whether it should be ansible handling the loop based on a passed in parameter. 'Ansible-native' looping is currently the case for the current deploy_steps_playbook here <a href="https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L335">https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L335</a> - can we not work parameterise that playbook so that we either do loop with the variable, or just step X? </div><div><br></div><div>Then for the upgrade workflow it is as above but  1.5 first launch the upgrade_tasks_playbook  then the deploy_steps playbook for all the steps (consider this  <a href="https://review.openstack.org/#/c/505624/3/scripts/upgrade-non-controller.sh@162">https://review.openstack.org/#/c/505624/3/scripts/upgrade-non-controller.sh@162</a> - download and run the playbooks for non-controllers in O->P upgrade pointing this out to illustrate the workflow I have in mind). So I don't see why we can't have mistral invoking ansible-playbook and taking parameters like which playbook, which step etc.</div></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"><div class="gmail-HOEnZb"><div class="gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
<br></div></div>
Alternatively we could do the main step loop in Ansible directly, and have the tasks do whatever they need to get the particular service deployed, from  to launching a nested ansible-playbook run if that's what it takes.<br></blockquote><div><br></div><div><br></div><div>I think you can do both, I mean mistral invoking ansible-playbook and still let ansible handle the steps with a loop. In fact that is what the current upgrade_steps_playbook does here <a href="https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L363-L365">https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L363-L365</a> with a loop variable 'step'. The upgrade_tasks have their 'tags: stepX' converted to 'when: step == X' in the client here  <a href="https://github.com/openstack/python-tripleoclient/blob/4d342826d6c3db38ee88dccc92363b655b1161a5/tripleoclient/v1/overcloud_config.py#L63">https://github.com/openstack/python-tripleoclient/blob/4d342826d6c3db38ee88dccc92363b655b1161a5/tripleoclient/v1/overcloud_config.py#L63</a>  - we must come up with a better solution than that; ultimately we can just update the existing upgrade_tasks to have 'when' and the main reason for not doing so already was not to break the heat-driven upgrade workflow but that is going away for Q.<br></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>
That way we could run the whole thing end-to-end via ansible-playbook, or if needed one could execute smaller bits by themselves (steps or nested playbook runs) -- that capability is not baked in by default, but i think we could make it so.<br>
<br>
Also the interface for services would be clean and simple -- it's always the ansible tasks.<br>
<br>
And Mistral-less use cases become easier to handle too (= undercloud installation when Mistral isn't present yet, or development envs when you want to tune the playbook directly without being forced to go through Mistral).<br></blockquote><div><br></div><div>You don't *have* to go through mistral either way I mean you can always just run ansible-playbook directly using the generated playbooks if that is what you need for dev/debug etc.<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>
Logging becomes a bit more unwieldy in this scenario though, as for the nested ansible-playbook execution, all output would go into a task in the outer playbook, which would be harder to follow and the log of the outer playbook could be huge.<br>
<br>
So this solution is no silver bullet, but from my current point of view it seems a bit less conceptually foreign than using Mistral to provide step loop functionality to Ansible, which should be able to handle that on its own.<div><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div>just saying using mistral to invoke ansible-playbook doesn't imply having mistral do the looping/step control. I think it was already mentioned that we can/will have multiple invocations of ansible-playbook. Having the loop in the playbook then means organising our templates a certain way so that there is a _single_ parent playbook which we can parameterise to then run all or some of the steps (which as pointed above is currently the case for the upgrade and deployment steps playbooks).</div><div><br></div><div><br></div><div>For me the main advantage of using mistral is the integration with UI - we've never had 'proper' client/common support for upgrades or updates and getting that is a goal for Q (<a href="https://etherpad.openstack.org/p/tripleo-ptg-queens-upgrades">https://etherpad.openstack.org/p/tripleo-ptg-queens-upgrades</a> - if nothing else, we need a more decent way of handling the ansible-playbook invocations than a bash script like upgrade-non-controller). There is already some relevant work under way here FYI <a href="https://review.openstack.org/#/c/487496/">https://review.openstack.org/#/c/487496/</a> <a href="https://review.openstack.org/#/c/487488/">https://review.openstack.org/#/c/487488/</a> that will be used for P minor update.</div><div><br></div><div>thanks, marios</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"><div><div class="gmail-h5">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- It would still be possible to run ansible-playbook directly for<br>
various use cases (dev/test/POC/demos). This preserves the quick<br>
iteration via Ansible that is often desired.<br>
<br>
- The remaining SoftwareDeployment resources in tripleo-heat-templates<br>
need to be supported by config download so that the entire<br>
configuration can be driven with Ansible, not just the deployment<br>
steps. The success criteria for this point would be to illustrate<br>
using an image that does not contain a running os-collect-config.<br>
<br>
- The ceph-ansible implementation done in Pike could be reworked to<br>
use this model. "config download" could generate playbooks that have<br>
hooks for calling external playbooks, or those hooks could be<br>
represented in the templates directly. The result would be the same<br>
either way though in that Heat would no longer be triggering a<br>
separate Mistral workflow just for ceph-ansible.<br>
</blockquote>
<br>
I'd say for ceph-ansible, kubernetes and in general anything else which<br>
needs to run with a standard playbook installed on the undercloud and<br>
not one generated via the heat templates... these "external" services<br>
usually require the inventory file to be in different format, to<br>
describe the hosts to use on a per-service basis, not per-role (and I<br>
mean tripleo roles here, not ansible roles obviously)<br>
<br>
About that, we discussed a more long term vision where the playbooks<br>
(static data) needd to describe how to deploy/upgrade a given service is<br>
in a separate repo (like tripleo-apb) and we "compose" from heat the<br>
list of playbooks to be executed based on the roles/enabled services; in<br>
this scenario we'd be much closer to what we had to do for ceph-ansible<br>
and I feel like that might finally allow us merge back the ceph<br>
deployment (or kubernetes deployment) process into the more general<br>
approach driven by tripleo<br>
<br>
James, Dan, comments?<br>
</blockquote>
<br>
Agreed, I think this is the longer term plan in regards to using<br>
APB's, where everything consumed is an external playbook/role.<br>
<br>
We definitely want to consider this plan in parallel with the POC work<br>
that Flavio is pulling together and make sure that they are aligned so<br>
that we're not constantly reworking the framework.<br>
<br>
I've not yet had a chance to review the material he sent out this<br>
morning, but perhaps we could work together to update the sequence<br>
diagram to also have a "future" state to indicate where we are going<br>
and what it would look like with APB's and external paybooks.<br>
</blockquote></blockquote>
<br></div></div>
Indeed that would be great :) IIUC, APBs are deployed by running a short-lived container with Ansible inside, which then connects to Kubernetes endpoint to create resources. So this should be a less complicated case than running non-containerized external playbooks.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
this would be awesome, note that it isn't only ceph and kubernetes<br>
anymore in this scenario ... I just spotted a submission for the Skydive<br>
composable service and it uses the same mistral/ansible-playbook<br>
approach ... so it's already 3 looking forward for this!<br>
<br>
<a href="https://review.openstack.org/#/c/502353/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/502353/</a><br>
<br>
</blockquote>
<br></span>
[1] <a href="https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/blob/master/docs/design.md#deploy" rel="noreferrer" target="_blank">https://github.com/ansibleplay<wbr>bookbundle/ansible-playbook-<wbr>bundle/blob/master/docs/<wbr>design.md#deploy</a><div class="gmail-HOEnZb"><div class="gmail-h5"><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>