On Fri, Sep 22, 2017 at 4:17 PM, Jiří Stránský <ji...@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ý <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. > > +1, especially the last part. I think it would be much easier for an operator to follow what is going on, if we have a (relatively) simpler mistral workbook to invoke the deployment playbooks (versus a bigger workbook that has to handle all the steps/looping etc). In the former case there would be one 'parent' playbook to go look at and then you could follow the trail of includes for other tasks/playbooks to get the 'big picture' for what happens when during the deployment. > 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. > > It is really very unfortunate that we would break the workflow tasks by doing this (and sounds like ceph-ansible is not the only one now). I wonder if there is a way we could keep both - if the ceph deploy can come "after all the things"/be completely decoupled? So we would have mistral --> ansible --> [?ansible]* for the deployment of all the other things, return, then invoke the ceph workflow tasks? Problem is that we immediately lose the simplification game there since we end up with something potentially more confusing. Still if this is possible it may be worth considering for the first iteration, assuming we go this way mistral->ansible, changing the ansible workflow tasks is hard/difficult/not possible, and we can do the ceph deploy after everything else (but there are a lot of 'if' in this paragraph :) ) thanks, marios > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ 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
