Open Stack

(cross-posting)

James and I created this etherpad:
https://etherpad.openstack.org/p/tripleo-config-download
which tracks work in progress for the config download efforts.

Please let us know any question on that topic,

On Mon, Sep 25, 2017 at 5:28 PM, Dan Prince <dprince at redhat.com> wrote:
>
>
> On Thu, Sep 21, 2017 at 8:53 AM, Jiří Stránský <jistr at redhat.com> wrote:
>>
>> On 21.9.2017 12:31, Giulio Fidente wrote:
>>>
>>> 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
>>>
>>
>> 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.
>>
>> 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.
>
>
> This was the idea that had the most traction at the PTG when we discussed
> it. Things can still be interleaved across the installers (stepwise) but we
> effectively eliminate the complexity of having multiple tools involved
> within the main deploy step loop as you described it.
>
> I think we should consider making it so that the main Ansible loop can call
> any external installer in a stepwise fashion though. It doesn't have to be
> just Ansible it calls. In this manner we would be supporting calling into
> multiple phases of an external installer.
>
> During the undercloud deployment we get all the benefits of Ansible driving
> our primary deployment loop and can still call into external installers like
> Kubernetes if we want to. On the overcloud we'd still be leveraging the high
> level Mistral workflow to kick off the initial Ansible playbooks... but once
> that happens it would be Ansible driving any external installers directly.
>
> Dan
>
>>
>>
>> Also the interface for services would be clean and simple -- it's always
>> the ansible tasks.
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>>
>>>>>> - 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.
>>
>>
>> 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.
>>
>>>
>>> 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/
>>>
>>
>> [1]
>> https://github.com/ansibleplaybookbundle/ansible-playbook-bundle/blob/master/docs/design.md#deploy
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi