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ý <ji...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
