[openstack-dev] [TripleO] TripleO/Ansible PTG session
jistr at redhat.com
Fri Sep 22 13:17:19 UTC 2017
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
>>>> 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
>>>> want to tune the playbook directly without being forced to go through
>>> 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
>>>> 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
>>> just saying using mistral to invoke ansible-playbook doesn't imply having
>>> mistral do the looping/step control. I think it was already mentioned
>>> we can/will have multiple invocations of ansible-playbook. Having the
>>> 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
>>> 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  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.
More information about the OpenStack-dev