Open Stack

>>> - 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.

So far, I think it aligns just fine. I would like to start playing with it and
see if I can leaverage this work directly instead of modifying the existing
templates we use for paunch.

Will look into the details of how this works and get back to you,
Flavio

--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170925/337e9678/attachment.sig>