Open Stack

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/workbooks/ceph-ansible.yaml