Open Stack

On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente <gfidente at redhat.com> wrote:
> On 09/18/2017 05:37 PM, James Slagle wrote:
>> - The entire sequence and flow is driven via Mistral on the Undercloud
>> by default. This preserves the API layer and provides a clean reusable
>> interface for the CLI and GUI.
>
> I think it's worth saying that we want to move the deployment steps out
> of heat and in ansible, not in mistral so that mistral will run the
> workflow only once and let ansible go through the steps
>
> I think having the steps in mistral would be a nice option to be able to
> rerun easily a particular deployment step from the GUI, versus having
> them in ansible which is instead a better option for CLI users ... but
> it looks like having them in ansible is the only option which permits us
> to reuse the same code to deploy an undercloud because having the steps
> in mistral would require the undercloud installation itself to depend on
> mistral which we don't want to
>
> James, Dan, please comment on the above if I am wrong

That's correct. We don't want to require Mistral to install the
Undercloud. However, I don't think that necessarily means it has to be
a single call to ansible-playbook. We could have multiple invocations
of ansible-playbook. Both Mistral and CLI code for installing the
undercloud could handle that easily.

You wouldn't be able to interleave an external playbook among the
deploy steps however. That would have to be done under a single call
to ansible-playbook (at least how that is written now). We could
however have hooks that could serve as integration points to call
external playbooks after each step.

>> - It would still be possible to run ansible-playbook directly for
>> various use cases (dev/test/POC/demos). This preserves the quick
>> iteration via Ansible that is often desired.
>>
>> - The remaining SoftwareDeployment resources in tripleo-heat-templates
>> need to be supported by config download so that the entire
>> configuration can be driven with Ansible, not just the deployment
>> steps. The success criteria for this point would be to illustrate
>> using an image that does not contain a running os-collect-config.
>>
>> - The ceph-ansible implementation done in Pike could be reworked to
>> use this model. "config download" could generate playbooks that have
>> hooks for calling external playbooks, or those hooks could be
>> represented in the templates directly. The result would be the same
>> either way though in that Heat would no longer be triggering a
>> separate Mistral workflow just for ceph-ansible.
>
> I'd say for ceph-ansible, kubernetes and in general anything else which
> needs to run with a standard playbook installed on the undercloud and
> not one generated via the heat templates... these "external" services
> usually require the inventory file to be in different format, to
> describe the hosts to use on a per-service basis, not per-role (and I
> mean tripleo roles here, not ansible roles obviously)
>
> About that, we discussed a more long term vision where the playbooks
> (static data) needd to describe how to deploy/upgrade a given service is
> in a separate repo (like tripleo-apb) and we "compose" from heat the
> list of playbooks to be executed based on the roles/enabled services; in
> this scenario we'd be much closer to what we had to do for ceph-ansible
> and I feel like that might finally allow us merge back the ceph
> deployment (or kubernetes deployment) process into the more general
> approach driven by tripleo
>
> James, Dan, comments?

Agreed, I think this is the longer term plan in regards to using
APB's, where everything consumed is an external playbook/role.

We definitely want to consider this plan in parallel with the POC work
that Flavio is pulling together and make sure that they are aligned so
that we're not constantly reworking the framework.

I've not yet had a chance to review the material he sent out this
morning, but perhaps we could work together to update the sequence
diagram to also have a "future" state to indicate where we are going
and what it would look like with APB's and external paybooks.


-- 
-- James Slagle
--