Open Stack

Will it be possible to send Zaqar messages at each deployment step to make
the deployment process more interactive? in case of driving separate
playbooks from mistral workflow, that would be absolutely possible. As it
seems we're more keen on driving everything from wrapping ansible playbook,
is it going to be possible to send Zaqar messages from ansible playbook
directly?

Being able to properly monitor progress of deployment is important so it
would be good to clarify how that is going to work.

-- Jirka

On Fri, Sep 22, 2017 at 3:17 PM, Jiří Stránský <jistr at redhat.com> wrote:

> On 22.9.2017 13:44, Giulio Fidente wrote:
>
>> On 09/21/2017 07:53 PM, Jiří Stránský wrote:
>>
>>> On 21.9.2017 18:04, Marios Andreou wrote:
>>>
>>>> On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský <jistr at redhat.com>
>>>> wrote:
>>>>
>>>
>> [...]
>>
>> 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.
>>>>>
>>>>> 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).
>>>>>
>>>>>
>>>> You don't *have* to go through mistral either way I mean you can always
>>>> just run ansible-playbook directly using the generated playbooks if
>>>> that is
>>>> what you need for dev/debug etc.
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> just saying using mistral to invoke ansible-playbook doesn't imply
>>>> having
>>>> mistral do the looping/step control. I think it was already mentioned
>>>> that
>>>> we can/will have multiple invocations of ansible-playbook. Having the
>>>> loop
>>>> in the playbook then means organising our templates a certain way so
>>>> that
>>>> there is a _single_ parent playbook which we can parameterise to then
>>>> run
>>>> all or some of the steps (which as pointed above is currently the case
>>>> for
>>>> the upgrade and deployment steps playbooks).
>>>>
>>>
>>> Yup, +1 again :) However, the 1)2)3)4) approach discussed earlier in the
>>> thread suggested to hand over the step loop control to Mistral and keep
>>> using the Mistral workflow_tasks, which would make it impossible to have
>>> a single parent playbook, if i understood correctly. So Mistral would be
>>> a requirement for running all steps via a single command (impacting UC
>>> install and developer workflow).
>>>
>>
>> yes I am not sold (yet?) on the idea of ansible driving the deployment
>> and would like to keep some abstraction before it
>>
>> the additional abstraction will make it possible for example to execute
>> tasks written as mistral actions (eg. python code) in between or during
>> any given deployment step, instead of ansible tasks only ... I guess we
>> could also write ansible actions in python but it's not trivial to ship
>> them from THT and given the project mission we have of being "openstack
>> on openstack" I'd also prefer writing a mistral action vs ansible
>>
>> similarily, the ceph-ansible workflow runs a task to build the ansible
>> inventory; if we make the "external" services integration an
>> ansible->ansible process we'll probably need to ship from THT an heat
>> query (or ansible task) to be executed by the "outer" ansible to create
>> the inventory for the inner ansible
>>
>
> Yea, allowing e2e software deployment with Ansible requires converting the
> current Mistral workflow_tasks into Ansible. In terms of services affected
> by this, there's in-tree ceph-ansible [1] and we have proposed patches for
> Kubernetes and Skydive (that's what i'm aware of).
>
>
>> I supported the introduction of mistral as an API and would prefer to
>> have there more informations there versus moving it away into YACT (yet
>> another configuration tool)
>>
>
> We could mitigate this somewhat by doing what Marios and James suggested
> -- running the global playbook one step at a time when the playbook is
> executed from Mistral. It will not give Mistral 100% of the information
> when compared with the approach you suggested, but it's a bit closer...
>
>
>> depending on mistral for the undercloud install is also not very
>> different from depending on heat(-all)
>>
>> I understand the ansible->ansible process addresses the "simplification"
>> issue we have been asked to look into; it is pretty much the only good
>> thing I see about it though :D
>>
>
> Right, it's a simpler design, which i consider important, as my hope is
> that over time it would result in some time&effort savings, hopefully not
> just among developers, but also operators, when having to debug things or
> reason about how TripleO works.
>
> Btw the points i didn't react to -- i mostly agree there :P. There are
> tradeoffs involved in both variants and it's not a clear-as-day choice for
> me either.
>
> Thanks :)
>
> Jirka
>
> [1] https://github.com/openstack/tripleo-common/blob/master/work
> books/ceph-ansible.yaml
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170922/cb2f48f8/attachment.html>