Open Stack

On 11/10/17 12:25 -0700, Emilien Macchi wrote:
>(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,

Thanks, this is useful!
Flavio

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

--
@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/20171012/165de21e/attachment.sig>