Open Stack

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

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)

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
-- 
Giulio Fidente
GPG KEY: 08D733BA