<div><br><div class="gmail_quote"><div dir="auto">st 20. 9. 2017 v 19:37 odesÃlatel James Slagle <<a href="mailto:james.slagle@gmail.com">james.slagle@gmail.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>
> On 09/18/2017 05:37 PM, James Slagle wrote:<br>
>> - 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>
><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>
<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.</blockquote><div dir="auto"><br></div><div dir="auto">Mistral workflow's input could hold a list of steps that would define which deploy steps ansible is going to go through. Is that correct assumption? On undercloud installation list of steps would be provided by CLI.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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.</blockquote><div dir="auto"><br></div><div dir="auto">Could an external playbook be triggered as a custom step provided in Mistral workflow input I mention above?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
>> - 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>
><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>
<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>
<br>
<br>
--<br>
-- James Slagle<br>
--</blockquote><div dir="auto"><br></div><div dir="auto">-- Jiri Tomasek</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>