Open Stack

On 09/20/2017 07:36 PM, James Slagle wrote:
> 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.

the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud

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

this would be awesome, note that it isn't only ceph and kubernetes
anymore in this scenario ... I just spotted a submission for the Skydive
composable service and it uses the same mistral/ansible-playbook
approach ... so it's already 3 looking forward for this!

https://review.openstack.org/#/c/502353/
-- 
Giulio Fidente
GPG KEY: 08D733BA