Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Flavio Percoco]

On 11/10/17 12:25 -0700, Emilien Macchi wrote:

(cross-posting)

James and I created this etherpad:
https://etherpad.openstack.org/p/tripleo-config-download
which tracks work in progress for the config download efforts.

Please let us know any question on that topic,


Thanks, this is useful!
Flavio


On Mon, Sep 25, 2017 at 5:28 PM, Dan Prince  wrote:



On Thu, Sep 21, 2017 at 8:53 AM, Jiří Stránský  wrote:


On 21.9.2017 12:31, Giulio Fidente wrote:


On 09/20/2017 07:36 PM, James Slagle wrote:


On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
wrote:


On 09/18/2017 05:37 PM, James Slagle wrote:


- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.



I think it's worth saying that we want to move the deployment steps out
of heat and in ansible, not in mistral so that mistral will run the
workflow only once and let ansible go through the steps

I think having the steps in mistral would be a nice option to be able
to
rerun easily a particular deployment step from the GUI, versus having
them in ansible which is instead a better option for CLI users ... but
it looks like having them in ansible is the only option which permits
us
to reuse the same code to deploy an undercloud because having the steps
in mistral would require the undercloud installation itself to depend
on
mistral which we don't want to

James, Dan, please comment on the above if I am wrong



That's correct. We don't want to require Mistral to install the
Undercloud. However, I don't think that necessarily means it has to be
a single call to ansible-playbook. We could have multiple invocations
of ansible-playbook. Both Mistral and CLI code for installing the
undercloud could handle that easily.

You wouldn't be able to interleave an external playbook among the
deploy steps however. That would have to be done under a single call
to ansible-playbook (at least how that is written now). We could
however have hooks that could serve as integration points to call
external playbooks after each step.



the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from
heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible
playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud



Alternatively we could do the main step loop in Ansible directly, and have
the tasks do whatever they need to get the particular service deployed, from
to launching a nested ansible-playbook run if that's what it takes.

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.



This was the idea that had the most traction at the PTG when we discussed
it. Things can still be interleaved across the installers (stepwise) but we
effectively eliminate the complexity of having multiple tools involved
within the main deploy step loop as you described it.

I think we should consider making it so that the main Ansible loop can call
any external installer in a stepwise fashion though. It doesn't have to be
just Ansible it calls. In this manner we would be supporting calling into
multiple phases of an external installer.

During the undercloud deployment we get all the benefits of Ansible driving
our primary deployment loop and can still call into external installers like
Kubernetes if we want to. On the overcloud we'd still be leveraging the high
level Mistral workflow to kick off the initial Ansible playbooks... but once
that happens it would be Ansible driving any external installers directly.

Dan




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).

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.



- It would still be possible to run ansible-playbook directly for
various 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Emilien Macchi]

(cross-posting)

James and I created this etherpad:
https://etherpad.openstack.org/p/tripleo-config-download
which tracks work in progress for the config download efforts.

Please let us know any question on that topic,

On Mon, Sep 25, 2017 at 5:28 PM, Dan Prince  wrote:
>
>
> On Thu, Sep 21, 2017 at 8:53 AM, Jiří Stránský  wrote:
>>
>> On 21.9.2017 12:31, Giulio Fidente wrote:
>>>
>>> On 09/20/2017 07:36 PM, James Slagle wrote:

 On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
 wrote:
>
> On 09/18/2017 05:37 PM, James Slagle wrote:
>>
>> - The entire sequence and flow is driven via Mistral on the Undercloud
>> by default. This preserves the API layer and provides a clean reusable
>> interface for the CLI and GUI.
>
>
> I think it's worth saying that we want to move the deployment steps out
> of heat and in ansible, not in mistral so that mistral will run the
> workflow only once and let ansible go through the steps
>
> I think having the steps in mistral would be a nice option to be able
> to
> rerun easily a particular deployment step from the GUI, versus having
> them in ansible which is instead a better option for CLI users ... but
> it looks like having them in ansible is the only option which permits
> us
> to reuse the same code to deploy an undercloud because having the steps
> in mistral would require the undercloud installation itself to depend
> on
> mistral which we don't want to
>
> James, Dan, please comment on the above if I am wrong


 That's correct. We don't want to require Mistral to install the
 Undercloud. However, I don't think that necessarily means it has to be
 a single call to ansible-playbook. We could have multiple invocations
 of ansible-playbook. Both Mistral and CLI code for installing the
 undercloud could handle that easily.

 You wouldn't be able to interleave an external playbook among the
 deploy steps however. That would have to be done under a single call
 to ansible-playbook (at least how that is written now). We could
 however have hooks that could serve as integration points to call
 external playbooks after each step.
>>>
>>>
>>> the benefits of driving the steps from mistral are that then we could
>>> also interleave the deployment steps and we won't need the
>>> ansible-playbook hook for the "external" services:
>>>
>>> 1) collect the ansible tasks *and* the workflow_tasks (per step) from
>>> heat
>>>
>>> 2) launch the stepN deployment workflow (ansible-playbook)
>>>
>>> 3) execute any workflow_task defined for stepN (like ceph-ansible
>>> playbook)
>>>
>>> 4) repeat 2 and 3 for stepN+1
>>>
>>> I think this would also provide a nice interface for the UI ... but then
>>> we'd need mistral to be able to deploy the undercloud
>>>
>>
>> Alternatively we could do the main step loop in Ansible directly, and have
>> the tasks do whatever they need to get the particular service deployed, from
>> to launching a nested ansible-playbook run if that's what it takes.
>>
>> 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.
>
>
> This was the idea that had the most traction at the PTG when we discussed
> it. Things can still be interleaved across the installers (stepwise) but we
> effectively eliminate the complexity of having multiple tools involved
> within the main deploy step loop as you described it.
>
> I think we should consider making it so that the main Ansible loop can call
> any external installer in a stepwise fashion though. It doesn't have to be
> just Ansible it calls. In this manner we would be supporting calling into
> multiple phases of an external installer.
>
> During the undercloud deployment we get all the benefits of Ansible driving
> our primary deployment loop and can still call into external installers like
> Kubernetes if we want to. On the overcloud we'd still be leveraging the high
> level Mistral workflow to kick off the initial Ansible playbooks... but once
> that happens it would be Ansible driving any external installers directly.
>
> Dan
>
>>
>>
>> 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).
>>
>> 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.
>>

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Dan Prince]

On Thu, Sep 21, 2017 at 8:53 AM, Jiří Stránský  wrote:

> On 21.9.2017 12:31, Giulio Fidente wrote:
>
>> On 09/20/2017 07:36 PM, James Slagle wrote:
>>
>>> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
>>> wrote:
>>>
 On 09/18/2017 05:37 PM, James Slagle wrote:

> - The entire sequence and flow is driven via Mistral on the Undercloud
> by default. This preserves the API layer and provides a clean reusable
> interface for the CLI and GUI.
>

 I think it's worth saying that we want to move the deployment steps out
 of heat and in ansible, not in mistral so that mistral will run the
 workflow only once and let ansible go through the steps

 I think having the steps in mistral would be a nice option to be able to
 rerun easily a particular deployment step from the GUI, versus having
 them in ansible which is instead a better option for CLI users ... but
 it looks like having them in ansible is the only option which permits us
 to reuse the same code to deploy an undercloud because having the steps
 in mistral would require the undercloud installation itself to depend on
 mistral which we don't want to

 James, Dan, please comment on the above if I am wrong

>>>
>>> That's correct. We don't want to require Mistral to install the
>>> Undercloud. However, I don't think that necessarily means it has to be
>>> a single call to ansible-playbook. We could have multiple invocations
>>> of ansible-playbook. Both Mistral and CLI code for installing the
>>> undercloud could handle that easily.
>>>
>>> You wouldn't be able to interleave an external playbook among the
>>> deploy steps however. That would have to be done under a single call
>>> to ansible-playbook (at least how that is written now). We could
>>> however have hooks that could serve as integration points to call
>>> external playbooks after each step.
>>>
>>
>> the benefits of driving the steps from mistral are that then we could
>> also interleave the deployment steps and we won't need the
>> ansible-playbook hook for the "external" services:
>>
>> 1) collect the ansible tasks *and* the workflow_tasks (per step) from heat
>>
>> 2) launch the stepN deployment workflow (ansible-playbook)
>>
>> 3) execute any workflow_task defined for stepN (like ceph-ansible
>> playbook)
>>
>> 4) repeat 2 and 3 for stepN+1
>>
>> I think this would also provide a nice interface for the UI ... but then
>> we'd need mistral to be able to deploy the undercloud
>>
>>
> Alternatively we could do the main step loop in Ansible directly, and have
> the tasks do whatever they need to get the particular service deployed,
> from  to launching a nested ansible-playbook run if that's what it takes.
>
> 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.
>

This was the idea that had the most traction at the PTG when we discussed
it. Things can still be interleaved across the installers (stepwise) but we
effectively eliminate the complexity of having multiple tools involved
within the main deploy step loop as you described it.

I think we should consider making it so that the main Ansible loop can call
any external installer in a stepwise fashion though. It doesn't have to be
just Ansible it calls. In this manner we would be supporting calling into
multiple phases of an external installer.

During the undercloud deployment we get all the benefits of Ansible driving
our primary deployment loop and can still call into external installers
like Kubernetes if we want to. On the overcloud we'd still be leveraging
the high level Mistral workflow to kick off the initial Ansible
playbooks... but once that happens it would be Ansible driving any external
installers directly.

Dan


>
> 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).
>
> 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.
>
>
> - It would still be possible to run ansible-playbook directly for
> various use cases (dev/test/POC/demos). This preserves the quick
> iteration via Ansible that is often desired.
>

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Flavio Percoco]

- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.


I'd say for ceph-ansible, kubernetes and in general anything else which
needs to run with a standard playbook installed on the undercloud and
not one generated via the heat templates... these "external" services
usually require the inventory file to be in different format, to
describe the hosts to use on a per-service basis, not per-role (and I
mean tripleo roles here, not ansible roles obviously)

About that, we discussed a more long term vision where the playbooks
(static data) needd to describe how to deploy/upgrade a given service is
in a separate repo (like tripleo-apb) and we "compose" from heat the
list of playbooks to be executed based on the roles/enabled services; in
this scenario we'd be much closer to what we had to do for ceph-ansible
and I feel like that might finally allow us merge back the ceph
deployment (or kubernetes deployment) process into the more general
approach driven by tripleo

James, Dan, comments?


Agreed, I think this is the longer term plan in regards to using
APB's, where everything consumed is an external playbook/role.

We definitely want to consider this plan in parallel with the POC work
that Flavio is pulling together and make sure that they are aligned so
that we're not constantly reworking the framework.

I've not yet had a chance to review the material he sent out this
morning, but perhaps we could work together to update the sequence
diagram to also have a "future" state to indicate where we are going
and what it would look like with APB's and external paybooks.


So far, I think it aligns just fine. I would like to start playing with it and
see if I can leaverage this work directly instead of modifying the existing
templates we use for paunch.

Will look into the details of how this works and get back to you,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Flavio Percoco]

On 18/09/17 09:37 -0600, James Slagle wrote:

On Wednesday at the PTG, TripleO held a session around our current use
of Ansible and how to move forward. I'll summarize the results of the
session. Feel free to add anything I forgot and provide any feedback
or questions.

We discussed the existing uses of Ansible in TripleO and how they
differ in terms of what they do and how they interact with Ansible. I
covered this in a previous email[1], so I'll skip over summarizing
those points again.

I explained a bit about the  "openstack overcloud config download"
approach implemented in Pike by the upgrades squad. This method
no-op's out the deployment steps during the actual Heat stack-update,
then uses the cli to query stack outputs to create actual Ansible
playbooks from those output values. The Undercloud is then used as the
Ansible runner to apply the playbooks to each Overcloud node.

I created a sequence diagram for this method and explained how it
would also work for initial stack deployment[2]:

https://slagle.fedorapeople.org/tripleo-ansible-arch.png

The high level proposal was to move in a direction where we'd use the
config download method for all Heat driven stack operations
(stack-create and stack-update).

We highlighted and discussed several key points about the method shown
in the diagram:

- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.

- It would still be possible to run ansible-playbook directly for
various use cases (dev/test/POC/demos). This preserves the quick
iteration via Ansible that is often desired.

- The remaining SoftwareDeployment resources in tripleo-heat-templates
need to be supported by config download so that the entire
configuration can be driven with Ansible, not just the deployment
steps. The success criteria for this point would be to illustrate
using an image that does not contain a running os-collect-config.

- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.

- We will need some centralized log storage for the ansible-playbook
results and should consider using ARA.

As it would be a lot of work to eventually make this method the
default, I don't expect or plan that we will complete all this work in
Queens. We can however start moving in this direction.

Specifically, I hope to soon add support to config download for the
rest of the SoftwareDeployment resources in tripleo-heat-templates as
that will greatly simplify the undercloud container installer. Doing
so will illustrate using the ephemeral heat-all process as simply a
means for generating ansible playbooks.

I plan to create blueprints this week for Queens and beyond. If you're
interested in this work, please let me know. I'm open to the idea of
creating an official squad for this work, but I'm not sure if it's
needed or not.

As not everyone was able to attend the PTG, please do provide feedback
about this plan as it should still be considered open for discussion.



Hey James,

sorry for getting back to this thread this late!

I like the approach and I think it makes sense for us to go down this path. As
far as my research on tripleo+kubernetes goes, I think this plan aligns quite
well with what I've been doing so far.

That said, I need to dive more into how `config download` works and start using
it for future demos and development.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Marios Andreou]

On Fri, Sep 22, 2017 at 4:17 PM, Jiří Stránský  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ý 
 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 savings, hopefully not
> just among developers, but also operators, when having to debug things or
> reason about how TripleO works.
>
>

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Marios Andreou]

On Thu, Sep 21, 2017 at 8: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ý  wrote:
>>
>> On 21.9.2017 12:31, Giulio Fidente wrote:
>>>
>>> On 09/20/2017 07:36 PM, James Slagle wrote:

 On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
> wrote:
>
> On 09/18/2017 05:37 PM, James Slagle wrote:
>>
>> - The entire sequence and flow is driven via Mistral on the Undercloud
>>> by default. This preserves the API layer and provides a clean
>>> reusable
>>> interface for the CLI and GUI.
>>>
>>>
>> I think it's worth saying that we want to move the deployment steps
>> out
>> of heat and in ansible, not in mistral so that mistral will run the
>> workflow only once and let ansible go through the steps
>>
>> I think having the steps in mistral would be a nice option to be able
>> to
>> rerun easily a particular deployment step from the GUI, versus having
>> them in ansible which is instead a better option for CLI users ... but
>> it looks like having them in ansible is the only option which permits
>> us
>> to reuse the same code to deploy an undercloud because having the
>> steps
>> in mistral would require the undercloud installation itself to depend
>> on
>> mistral which we don't want to
>>
>> James, Dan, please comment on the above if I am wrong
>>
>>
> That's correct. We don't want to require Mistral to install the
> Undercloud. However, I don't think that necessarily means it has to be
> a single call to ansible-playbook. We could have multiple invocations
> of ansible-playbook. Both Mistral and CLI code for installing the
> undercloud could handle that easily.
>
> You wouldn't be able to interleave an external playbook among the
> deploy steps however. That would have to be done under a single call
> to ansible-playbook (at least how that is written now). We could
> however have hooks that could serve as integration points to call
> external playbooks after each step.
>
>
 the benefits of driving the steps from mistral are that then we could
 also interleave the deployment steps and we won't need the
 ansible-playbook hook for the "external" services:

 1) collect the ansible tasks *and* the workflow_tasks (per step) from
 heat

 2) launch the stepN deployment workflow (ansible-playbook)

 3) execute any workflow_task defined for stepN (like ceph-ansible
 playbook)

 4) repeat 2 and 3 for stepN+1

 I think this would also provide a nice interface for the UI ... but then
 we'd need mistral to be able to deploy the undercloud



>> Why not launch the _single_  deploy_steps playbook (so we have
>> when/conditionals with step numbers), passing in the step you want to have
>> executed (we can pass this in as a parameter to the mistral workflow and
>> pass through to the ansible-playbook invocation?), otherwise execute all
>> the steps.
>>
>
> +1 that's the sort of thing i meant by "it's not baked in by default but
> we could make it so". We could even give it a list of steps like
> `tripleo_run_steps: [4, 5, 6]`.
>
> In either case whether it should be ansible handling the loop
>> based on a passed in parameter.
>> 'Ansible-native' looping is currently the
>> case for the current deploy_steps_playbook here
>> https://github.com/openstack/tripleo-heat-templates/blob/259
>> cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L335
>> - can we not work parameterise that playbook so that we either do loop
>> with
>> the variable, or just step X?
>>
>> Then for the upgrade workflow it is as above but  1.5 first launch the
>> upgrade_tasks_playbook  then the deploy_steps playbook for all the steps
>> (consider this
>> https://review.openstack.org/#/c/505624/3/scripts/upgrade-no
>> n-controller.sh@162
>> - download and run the playbooks for non-controllers in O->P upgrade
>> pointing this out to illustrate the workflow I have in mind). So I don't
>> see why we can't have mistral invoking ansible-playbook and taking
>> parameters like which playbook, which step etc.
>>
>>
>>
>>> Alternatively we could do the main step loop in Ansible directly, and
>>> have
>>> the tasks do whatever they need to get the particular service deployed,
>>> from  to launching a nested ansible-playbook run if that's what it takes.
>>>
>>>
>>
>> I think you can do both, I mean mistral invoking ansible-playbook and
>> still
>> let ansible handle the steps with a loop.
>>
>
> +1 exactly. FWIW i'm totally on board with wrapping everything in Mistral
> on the outermost level, as that's required for UI. I'm just not keen on
> having Mistral enter the process in between each step and drive the step
> loop.
>
> In fact that is what the current
>> 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Jiří Stránský]

On 22.9.2017 15:30, Jiri Tomasek wrote:

Will it be possible to send Zaqar messages at each deployment step to make
the deployment process more interactive?


If we go the way of allowing the wrapping playbook to execute per step, 
i think we could send messages to Zaqar after each step. Mistral could 
trigger the playbook with sth like `tripleo_run_steps: [1]`, then with 
`tripleo_run_steps: [2]` etc. So even though the playbook would support 
running all steps by default, Mistral could run it step-by-step.


(Currently we only send Zaqar messages before Heat stack and after Heat 
stack, is that right? [1] Or do we send & read some messages from within 
the overcloud stack deployment too?)


With logs from external playbooks (like ceph-ansible) it would be less 
comfy than it is now, or would require extra effort to improve on that. 
Currently AFAIK we don't send any Zaqar messages there anyway [2], but 
we at least publish the logs into Mistral separately from the rest of 
deployment logs. If we trigger an external playbook from Ansible, making 
it a "normal citizen" of a TripleO deployment step, then the external 
playbook logs would be reported along with logs of that whole deployment 
step. This is IMO the main weak point of having the step loop in Ansible 
(assuming its most basic form), perhaps something where we could find an 
improvement, e.g. utilizing ARA as James suggested earlier in the 
thread. (I don't know enough about ARA at this point to suggest a 
particular way of integrating it with Mistral/UI though.)



in case of driving separate
playbooks from mistral workflow, that would be absolutely possible. As it
seems we're more keen on driving everything from wrapping ansible playbook,
is it going to be possible to send Zaqar messages from ansible playbook
directly?


I did a quick search but didn't find any existing Ansible module for 
this. If we needed/wanted this for additional granularity, we might have 
to implement it.




Being able to properly monitor progress of deployment is important so it
would be good to clarify how that is going to work.

-- Jirka


[1] 
https://github.com/openstack/tripleo-common/blob/979dc308e51bb9b8e7b66b4258da1d67e50d9c2b/workbooks/deployment.yaml#L180
[2] 
https://github.com/openstack/tripleo-common/blob/979dc308e51bb9b8e7b66b4258da1d67e50d9c2b/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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Jiri Tomasek]

Will it be possible to send Zaqar messages at each deployment step to make
the deployment process more interactive? in case of driving separate
playbooks from mistral workflow, that would be absolutely possible. As it
seems we're more keen on driving everything from wrapping ansible playbook,
is it going to be possible to send Zaqar messages from ansible playbook
directly?

Being able to properly monitor progress of deployment is important so it
would be good to clarify how that is going to work.

-- Jirka

On Fri, Sep 22, 2017 at 3:17 PM, Jiří Stránský  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ý 
 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 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Jiří Stránský]

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ý  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 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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Giulio Fidente]

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ý  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

__
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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[James Slagle]

On Thu, Sep 21, 2017 at 11:53 AM, 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ý  wrote:
>>
>>> On 21.9.2017 12:31, Giulio Fidente wrote:
>>>
 On 09/20/2017 07:36 PM, James Slagle wrote:

> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
> wrote:
>
>> On 09/18/2017 05:37 PM, James Slagle wrote:
>>
>>> - The entire sequence and flow is driven via Mistral on the
>>> Undercloud
>>> by default. This preserves the API layer and provides a clean
>>> reusable
>>> interface for the CLI and GUI.
>>>
>>
>> I think it's worth saying that we want to move the deployment steps
>> out
>> of heat and in ansible, not in mistral so that mistral will run the
>> workflow only once and let ansible go through the steps
>>
>> I think having the steps in mistral would be a nice option to be able
>> to
>> rerun easily a particular deployment step from the GUI, versus having
>> them in ansible which is instead a better option for CLI users ... but
>> it looks like having them in ansible is the only option which permits
>> us
>> to reuse the same code to deploy an undercloud because having the
>> steps
>> in mistral would require the undercloud installation itself to depend
>> on
>> mistral which we don't want to
>>
>> James, Dan, please comment on the above if I am wrong
>>
>
> That's correct. We don't want to require Mistral to install the
> Undercloud. However, I don't think that necessarily means it has to be
> a single call to ansible-playbook. We could have multiple invocations
> of ansible-playbook. Both Mistral and CLI code for installing the
> undercloud could handle that easily.
>
> You wouldn't be able to interleave an external playbook among the
> deploy steps however. That would have to be done under a single call
> to ansible-playbook (at least how that is written now). We could
> however have hooks that could serve as integration points to call
> external playbooks after each step.
>

 the benefits of driving the steps from mistral are that then we could
 also interleave the deployment steps and we won't need the
 ansible-playbook hook for the "external" services:

 1) collect the ansible tasks *and* the workflow_tasks (per step) from
 heat

 2) launch the stepN deployment workflow (ansible-playbook)

 3) execute any workflow_task defined for stepN (like ceph-ansible
 playbook)

 4) repeat 2 and 3 for stepN+1

 I think this would also provide a nice interface for the UI ... but then
 we'd need mistral to be able to deploy the undercloud


>>
>> Why not launch the _single_  deploy_steps playbook (so we have
>> when/conditionals with step numbers), passing in the step you want to have
>> executed (we can pass this in as a parameter to the mistral workflow and
>> pass through to the ansible-playbook invocation?), otherwise execute all
>> the steps.
>
>
> +1 that's the sort of thing i meant by "it's not baked in by default but we
> could make it so". We could even give it a list of steps like
> `tripleo_run_steps: [4, 5, 6]`.

Agreed. We can parameterize as needed so that it could be driven via
Mistral for finer grained control for the API/UI or by a single
ansible-playbook directly.




-- 
-- James Slagle
--

__
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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Jiří Stránský]

On 21.9.2017 18:04, Marios Andreou wrote:

On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský  wrote:


On 21.9.2017 12:31, Giulio Fidente wrote:


On 09/20/2017 07:36 PM, James Slagle wrote:


On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
wrote:


On 09/18/2017 05:37 PM, James Slagle wrote:


- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.



I think it's worth saying that we want to move the deployment steps out
of heat and in ansible, not in mistral so that mistral will run the
workflow only once and let ansible go through the steps

I think having the steps in mistral would be a nice option to be able to
rerun easily a particular deployment step from the GUI, versus having
them in ansible which is instead a better option for CLI users ... but
it looks like having them in ansible is the only option which permits us
to reuse the same code to deploy an undercloud because having the steps
in mistral would require the undercloud installation itself to depend on
mistral which we don't want to

James, Dan, please comment on the above if I am wrong



That's correct. We don't want to require Mistral to install the
Undercloud. However, I don't think that necessarily means it has to be
a single call to ansible-playbook. We could have multiple invocations
of ansible-playbook. Both Mistral and CLI code for installing the
undercloud could handle that easily.

You wouldn't be able to interleave an external playbook among the
deploy steps however. That would have to be done under a single call
to ansible-playbook (at least how that is written now). We could
however have hooks that could serve as integration points to call
external playbooks after each step.



the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible
playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud




Why not launch the _single_  deploy_steps playbook (so we have
when/conditionals with step numbers), passing in the step you want to have
executed (we can pass this in as a parameter to the mistral workflow and
pass through to the ansible-playbook invocation?), otherwise execute all
the steps.


+1 that's the sort of thing i meant by "it's not baked in by default but 
we could make it so". We could even give it a list of steps like 
`tripleo_run_steps: [4, 5, 6]`.



In either case whether it should be ansible handling the loop
based on a passed in parameter.
'Ansible-native' looping is currently the
case for the current deploy_steps_playbook here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L335
- can we not work parameterise that playbook so that we either do loop with
the variable, or just step X?

Then for the upgrade workflow it is as above but  1.5 first launch the
upgrade_tasks_playbook  then the deploy_steps playbook for all the steps
(consider this
https://review.openstack.org/#/c/505624/3/scripts/upgrade-non-controller.sh@162
- download and run the playbooks for non-controllers in O->P upgrade
pointing this out to illustrate the workflow I have in mind). So I don't
see why we can't have mistral invoking ansible-playbook and taking
parameters like which playbook, which step etc.




Alternatively we could do the main step loop in Ansible directly, and have
the tasks do whatever they need to get the particular service deployed,
from  to launching a nested ansible-playbook run if that's what it takes.




I think you can do both, I mean mistral invoking ansible-playbook and still
let ansible handle the steps with a loop.


+1 exactly. FWIW i'm totally on board with wrapping everything in 
Mistral on the outermost level, as that's required for UI. I'm just not 
keen on having Mistral enter the process in between each step and drive 
the step loop.



In fact that is what the current
upgrade_steps_playbook does here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L363-L365
with a loop variable 'step'. The upgrade_tasks have their 'tags: stepX'
converted to 'when: step == X' in the client here
https://github.com/openstack/python-tripleoclient/blob/4d342826d6c3db38ee88dccc92363b655b1161a5/tripleoclient/v1/overcloud_config.py#L63
- we must come up with a better solution than that; ultimately we can just
update the existing upgrade_tasks to have 'when' and the main reason for
not doing so already was not to 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Marios Andreou]

On Thu, Sep 21, 2017 at 3:53 PM, Jiří Stránský  wrote:

> On 21.9.2017 12:31, Giulio Fidente wrote:
>
>> On 09/20/2017 07:36 PM, James Slagle wrote:
>>
>>> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
>>> wrote:
>>>
 On 09/18/2017 05:37 PM, James Slagle wrote:

> - The entire sequence and flow is driven via Mistral on the Undercloud
> by default. This preserves the API layer and provides a clean reusable
> interface for the CLI and GUI.
>

 I think it's worth saying that we want to move the deployment steps out
 of heat and in ansible, not in mistral so that mistral will run the
 workflow only once and let ansible go through the steps

 I think having the steps in mistral would be a nice option to be able to
 rerun easily a particular deployment step from the GUI, versus having
 them in ansible which is instead a better option for CLI users ... but
 it looks like having them in ansible is the only option which permits us
 to reuse the same code to deploy an undercloud because having the steps
 in mistral would require the undercloud installation itself to depend on
 mistral which we don't want to

 James, Dan, please comment on the above if I am wrong

>>>
>>> That's correct. We don't want to require Mistral to install the
>>> Undercloud. However, I don't think that necessarily means it has to be
>>> a single call to ansible-playbook. We could have multiple invocations
>>> of ansible-playbook. Both Mistral and CLI code for installing the
>>> undercloud could handle that easily.
>>>
>>> You wouldn't be able to interleave an external playbook among the
>>> deploy steps however. That would have to be done under a single call
>>> to ansible-playbook (at least how that is written now). We could
>>> however have hooks that could serve as integration points to call
>>> external playbooks after each step.
>>>
>>
>> the benefits of driving the steps from mistral are that then we could
>> also interleave the deployment steps and we won't need the
>> ansible-playbook hook for the "external" services:
>>
>> 1) collect the ansible tasks *and* the workflow_tasks (per step) from heat
>>
>> 2) launch the stepN deployment workflow (ansible-playbook)
>>
>> 3) execute any workflow_task defined for stepN (like ceph-ansible
>> playbook)
>>
>> 4) repeat 2 and 3 for stepN+1
>>
>> I think this would also provide a nice interface for the UI ... but then
>> we'd need mistral to be able to deploy the undercloud
>>
>>

Why not launch the _single_  deploy_steps playbook (so we have
when/conditionals with step numbers), passing in the step you want to have
executed (we can pass this in as a parameter to the mistral workflow and
pass through to the ansible-playbook invocation?), otherwise execute all
the steps. In either case whether it should be ansible handling the loop
based on a passed in parameter. 'Ansible-native' looping is currently the
case for the current deploy_steps_playbook here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L335
- can we not work parameterise that playbook so that we either do loop with
the variable, or just step X?

Then for the upgrade workflow it is as above but  1.5 first launch the
upgrade_tasks_playbook  then the deploy_steps playbook for all the steps
(consider this
https://review.openstack.org/#/c/505624/3/scripts/upgrade-non-controller.sh@162
- download and run the playbooks for non-controllers in O->P upgrade
pointing this out to illustrate the workflow I have in mind). So I don't
see why we can't have mistral invoking ansible-playbook and taking
parameters like which playbook, which step etc.


>
> Alternatively we could do the main step loop in Ansible directly, and have
> the tasks do whatever they need to get the particular service deployed,
> from  to launching a nested ansible-playbook run if that's what it takes.
>


I think you can do both, I mean mistral invoking ansible-playbook and still
let ansible handle the steps with a loop. In fact that is what the current
upgrade_steps_playbook does here
https://github.com/openstack/tripleo-heat-templates/blob/259cf512b3b7e3539105cdb52421e3239701ef73/common/deploy-steps.j2#L363-L365
with a loop variable 'step'. The upgrade_tasks have their 'tags: stepX'
converted to 'when: step == X' in the client here
https://github.com/openstack/python-tripleoclient/blob/4d342826d6c3db38ee88dccc92363b655b1161a5/tripleoclient/v1/overcloud_config.py#L63
- we must come up with a better solution than that; ultimately we can just
update the existing upgrade_tasks to have 'when' and the main reason for
not doing so already was not to break the heat-driven upgrade workflow but
that is going away for Q.



>
> 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 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Jiří Stránský]

On 21.9.2017 12:31, Giulio Fidente wrote:

On 09/20/2017 07:36 PM, James Slagle wrote:

On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente  wrote:

On 09/18/2017 05:37 PM, James Slagle wrote:

- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.


I think it's worth saying that we want to move the deployment steps out
of heat and in ansible, not in mistral so that mistral will run the
workflow only once and let ansible go through the steps

I think having the steps in mistral would be a nice option to be able to
rerun easily a particular deployment step from the GUI, versus having
them in ansible which is instead a better option for CLI users ... but
it looks like having them in ansible is the only option which permits us
to reuse the same code to deploy an undercloud because having the steps
in mistral would require the undercloud installation itself to depend on
mistral which we don't want to

James, Dan, please comment on the above if I am wrong


That's correct. We don't want to require Mistral to install the
Undercloud. However, I don't think that necessarily means it has to be
a single call to ansible-playbook. We could have multiple invocations
of ansible-playbook. Both Mistral and CLI code for installing the
undercloud could handle that easily.

You wouldn't be able to interleave an external playbook among the
deploy steps however. That would have to be done under a single call
to ansible-playbook (at least how that is written now). We could
however have hooks that could serve as integration points to call
external playbooks after each step.


the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud



Alternatively we could do the main step loop in Ansible directly, and 
have the tasks do whatever they need to get the particular service 
deployed, from  to launching a nested ansible-playbook run if that's 
what it takes.


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).


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.



- It would still be possible to run ansible-playbook directly for
various use cases (dev/test/POC/demos). This preserves the quick
iteration via Ansible that is often desired.

- The remaining SoftwareDeployment resources in tripleo-heat-templates
need to be supported by config download so that the entire
configuration can be driven with Ansible, not just the deployment
steps. The success criteria for this point would be to illustrate
using an image that does not contain a running os-collect-config.

- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.


I'd say for ceph-ansible, kubernetes and in general anything else which
needs to run with a standard playbook installed on the undercloud and
not one generated via the heat templates... these "external" services
usually require the inventory file to be in different format, to
describe the hosts to use on a per-service basis, not per-role (and I
mean tripleo roles here, not ansible roles obviously)

About that, we discussed a more long term vision where the playbooks
(static data) needd to describe how to deploy/upgrade a given service is
in a separate repo 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Giulio Fidente]

On 09/20/2017 07:36 PM, James Slagle wrote:
> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente  wrote:
>> On 09/18/2017 05:37 PM, James Slagle wrote:
>>> - The entire sequence and flow is driven via Mistral on the Undercloud
>>> by default. This preserves the API layer and provides a clean reusable
>>> interface for the CLI and GUI.
>>
>> I think it's worth saying that we want to move the deployment steps out
>> of heat and in ansible, not in mistral so that mistral will run the
>> workflow only once and let ansible go through the steps
>>
>> I think having the steps in mistral would be a nice option to be able to
>> rerun easily a particular deployment step from the GUI, versus having
>> them in ansible which is instead a better option for CLI users ... but
>> it looks like having them in ansible is the only option which permits us
>> to reuse the same code to deploy an undercloud because having the steps
>> in mistral would require the undercloud installation itself to depend on
>> mistral which we don't want to
>>
>> James, Dan, please comment on the above if I am wrong
> 
> That's correct. We don't want to require Mistral to install the
> Undercloud. However, I don't think that necessarily means it has to be
> a single call to ansible-playbook. We could have multiple invocations
> of ansible-playbook. Both Mistral and CLI code for installing the
> undercloud could handle that easily.
> 
> You wouldn't be able to interleave an external playbook among the
> deploy steps however. That would have to be done under a single call
> to ansible-playbook (at least how that is written now). We could
> however have hooks that could serve as integration points to call
> external playbooks after each step.

the benefits of driving the steps from mistral are that then we could
also interleave the deployment steps and we won't need the
ansible-playbook hook for the "external" services:

1) collect the ansible tasks *and* the workflow_tasks (per step) from heat

2) launch the stepN deployment workflow (ansible-playbook)

3) execute any workflow_task defined for stepN (like ceph-ansible playbook)

4) repeat 2 and 3 for stepN+1

I think this would also provide a nice interface for the UI ... but then
we'd need mistral to be able to deploy the undercloud

>>> - It would still be possible to run ansible-playbook directly for
>>> various use cases (dev/test/POC/demos). This preserves the quick
>>> iteration via Ansible that is often desired.
>>>
>>> - The remaining SoftwareDeployment resources in tripleo-heat-templates
>>> need to be supported by config download so that the entire
>>> configuration can be driven with Ansible, not just the deployment
>>> steps. The success criteria for this point would be to illustrate
>>> using an image that does not contain a running os-collect-config.
>>>
>>> - The ceph-ansible implementation done in Pike could be reworked to
>>> use this model. "config download" could generate playbooks that have
>>> hooks for calling external playbooks, or those hooks could be
>>> represented in the templates directly. The result would be the same
>>> either way though in that Heat would no longer be triggering a
>>> separate Mistral workflow just for ceph-ansible.
>>
>> I'd say for ceph-ansible, kubernetes and in general anything else which
>> needs to run with a standard playbook installed on the undercloud and
>> not one generated via the heat templates... these "external" services
>> usually require the inventory file to be in different format, to
>> describe the hosts to use on a per-service basis, not per-role (and I
>> mean tripleo roles here, not ansible roles obviously)
>>
>> About that, we discussed a more long term vision where the playbooks
>> (static data) needd to describe how to deploy/upgrade a given service is
>> in a separate repo (like tripleo-apb) and we "compose" from heat the
>> list of playbooks to be executed based on the roles/enabled services; in
>> this scenario we'd be much closer to what we had to do for ceph-ansible
>> and I feel like that might finally allow us merge back the ceph
>> deployment (or kubernetes deployment) process into the more general
>> approach driven by tripleo
>>
>> James, Dan, comments?
> 
> Agreed, I think this is the longer term plan in regards to using
> APB's, where everything consumed is an external playbook/role.
> 
> We definitely want to consider this plan in parallel with the POC work
> that Flavio is pulling together and make sure that they are aligned so
> that we're not constantly reworking the framework.
> 
> I've not yet had a chance to review the material he sent out this
> morning, but perhaps we could work together to update the sequence
> diagram to also have a "future" state to indicate where we are going
> and what it would look like with APB's and external paybooks.

this would be awesome, note that it isn't only ceph and kubernetes
anymore in this scenario ... I just spotted a submission for the Skydive

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Jiri Tomasek]

st 20. 9. 2017 v 19:37 odesílatel James Slagle 
napsal:

> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
> wrote:
> > On 09/18/2017 05:37 PM, James Slagle wrote:
> >> - The entire sequence and flow is driven via Mistral on the Undercloud
> >> by default. This preserves the API layer and provides a clean reusable
> >> interface for the CLI and GUI.
> >
> > I think it's worth saying that we want to move the deployment steps out
> > of heat and in ansible, not in mistral so that mistral will run the
> > workflow only once and let ansible go through the steps
> >
> > I think having the steps in mistral would be a nice option to be able to
> > rerun easily a particular deployment step from the GUI, versus having
> > them in ansible which is instead a better option for CLI users ... but
> > it looks like having them in ansible is the only option which permits us
> > to reuse the same code to deploy an undercloud because having the steps
> > in mistral would require the undercloud installation itself to depend on
> > mistral which we don't want to
> >
> > James, Dan, please comment on the above if I am wrong
>
> That's correct. We don't want to require Mistral to install the
> Undercloud. However, I don't think that necessarily means it has to be
> a single call to ansible-playbook. We could have multiple invocations
> of ansible-playbook. Both Mistral and CLI code for installing the
> undercloud could handle that easily.


Mistral workflow's input could hold a list of steps that would define which
deploy steps ansible is going to go through. Is that correct assumption? On
undercloud installation list of steps would be provided by CLI.


>
> You wouldn't be able to interleave an external playbook among the
> deploy steps however. That would have to be done under a single call
> to ansible-playbook (at least how that is written now). We could
> however have hooks that could serve as integration points to call
> external playbooks after each step.


Could an external playbook be triggered as a custom step provided in
Mistral workflow input I mention above?


>
> >> - It would still be possible to run ansible-playbook directly for
> >> various use cases (dev/test/POC/demos). This preserves the quick
> >> iteration via Ansible that is often desired.
> >>
> >> - The remaining SoftwareDeployment resources in tripleo-heat-templates
> >> need to be supported by config download so that the entire
> >> configuration can be driven with Ansible, not just the deployment
> >> steps. The success criteria for this point would be to illustrate
> >> using an image that does not contain a running os-collect-config.
> >>
> >> - The ceph-ansible implementation done in Pike could be reworked to
> >> use this model. "config download" could generate playbooks that have
> >> hooks for calling external playbooks, or those hooks could be
> >> represented in the templates directly. The result would be the same
> >> either way though in that Heat would no longer be triggering a
> >> separate Mistral workflow just for ceph-ansible.
> >
> > I'd say for ceph-ansible, kubernetes and in general anything else which
> > needs to run with a standard playbook installed on the undercloud and
> > not one generated via the heat templates... these "external" services
> > usually require the inventory file to be in different format, to
> > describe the hosts to use on a per-service basis, not per-role (and I
> > mean tripleo roles here, not ansible roles obviously)
> >
> > About that, we discussed a more long term vision where the playbooks
> > (static data) needd to describe how to deploy/upgrade a given service is
> > in a separate repo (like tripleo-apb) and we "compose" from heat the
> > list of playbooks to be executed based on the roles/enabled services; in
> > this scenario we'd be much closer to what we had to do for ceph-ansible
> > and I feel like that might finally allow us merge back the ceph
> > deployment (or kubernetes deployment) process into the more general
> > approach driven by tripleo
> >
> > James, Dan, comments?
>
> Agreed, I think this is the longer term plan in regards to using
> APB's, where everything consumed is an external playbook/role.
>
> We definitely want to consider this plan in parallel with the POC work
> that Flavio is pulling together and make sure that they are aligned so
> that we're not constantly reworking the framework.
>
> I've not yet had a chance to review the material he sent out this
> morning, but perhaps we could work together to update the sequence
> diagram to also have a "future" state to indicate where we are going
> and what it would look like with APB's and external paybooks.
>
>
> --
> -- James Slagle
> --


-- Jiri Tomasek


> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[James Slagle]

On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente  wrote:
> On 09/18/2017 05:37 PM, James Slagle wrote:
>> - The entire sequence and flow is driven via Mistral on the Undercloud
>> by default. This preserves the API layer and provides a clean reusable
>> interface for the CLI and GUI.
>
> I think it's worth saying that we want to move the deployment steps out
> of heat and in ansible, not in mistral so that mistral will run the
> workflow only once and let ansible go through the steps
>
> I think having the steps in mistral would be a nice option to be able to
> rerun easily a particular deployment step from the GUI, versus having
> them in ansible which is instead a better option for CLI users ... but
> it looks like having them in ansible is the only option which permits us
> to reuse the same code to deploy an undercloud because having the steps
> in mistral would require the undercloud installation itself to depend on
> mistral which we don't want to
>
> James, Dan, please comment on the above if I am wrong

That's correct. We don't want to require Mistral to install the
Undercloud. However, I don't think that necessarily means it has to be
a single call to ansible-playbook. We could have multiple invocations
of ansible-playbook. Both Mistral and CLI code for installing the
undercloud could handle that easily.

You wouldn't be able to interleave an external playbook among the
deploy steps however. That would have to be done under a single call
to ansible-playbook (at least how that is written now). We could
however have hooks that could serve as integration points to call
external playbooks after each step.

>> - It would still be possible to run ansible-playbook directly for
>> various use cases (dev/test/POC/demos). This preserves the quick
>> iteration via Ansible that is often desired.
>>
>> - The remaining SoftwareDeployment resources in tripleo-heat-templates
>> need to be supported by config download so that the entire
>> configuration can be driven with Ansible, not just the deployment
>> steps. The success criteria for this point would be to illustrate
>> using an image that does not contain a running os-collect-config.
>>
>> - The ceph-ansible implementation done in Pike could be reworked to
>> use this model. "config download" could generate playbooks that have
>> hooks for calling external playbooks, or those hooks could be
>> represented in the templates directly. The result would be the same
>> either way though in that Heat would no longer be triggering a
>> separate Mistral workflow just for ceph-ansible.
>
> I'd say for ceph-ansible, kubernetes and in general anything else which
> needs to run with a standard playbook installed on the undercloud and
> not one generated via the heat templates... these "external" services
> usually require the inventory file to be in different format, to
> describe the hosts to use on a per-service basis, not per-role (and I
> mean tripleo roles here, not ansible roles obviously)
>
> About that, we discussed a more long term vision where the playbooks
> (static data) needd to describe how to deploy/upgrade a given service is
> in a separate repo (like tripleo-apb) and we "compose" from heat the
> list of playbooks to be executed based on the roles/enabled services; in
> this scenario we'd be much closer to what we had to do for ceph-ansible
> and I feel like that might finally allow us merge back the ceph
> deployment (or kubernetes deployment) process into the more general
> approach driven by tripleo
>
> James, Dan, comments?

Agreed, I think this is the longer term plan in regards to using
APB's, where everything consumed is an external playbook/role.

We definitely want to consider this plan in parallel with the POC work
that Flavio is pulling together and make sure that they are aligned so
that we're not constantly reworking the framework.

I've not yet had a chance to review the material he sent out this
morning, but perhaps we could work together to update the sequence
diagram to also have a "future" state to indicate where we are going
and what it would look like with APB's and external paybooks.


-- 
-- James Slagle
--

__
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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Giulio Fidente]

On 09/18/2017 05:37 PM, James Slagle wrote:
> On Wednesday at the PTG, TripleO held a session around our current use
> of Ansible and how to move forward. I'll summarize the results of the
> session. Feel free to add anything I forgot and provide any feedback
> or questions.

thanks for starting this!

> We discussed the existing uses of Ansible in TripleO and how they
> differ in terms of what they do and how they interact with Ansible. I
> covered this in a previous email[1], so I'll skip over summarizing
> those points again.
> 
> I explained a bit about the  "openstack overcloud config download"
> approach implemented in Pike by the upgrades squad. This method
> no-op's out the deployment steps during the actual Heat stack-update,
> then uses the cli to query stack outputs to create actual Ansible
> playbooks from those output values. The Undercloud is then used as the
> Ansible runner to apply the playbooks to each Overcloud node.
> 
> I created a sequence diagram for this method and explained how it
> would also work for initial stack deployment[2]:
> 
> https://slagle.fedorapeople.org/tripleo-ansible-arch.png
> 
> The high level proposal was to move in a direction where we'd use the
> config download method for all Heat driven stack operations
> (stack-create and stack-update).
> 
> We highlighted and discussed several key points about the method shown
> in the diagram:
> 
> - The entire sequence and flow is driven via Mistral on the Undercloud
> by default. This preserves the API layer and provides a clean reusable
> interface for the CLI and GUI.

I think it's worth saying that we want to move the deployment steps out
of heat and in ansible, not in mistral so that mistral will run the
workflow only once and let ansible go through the steps

I think having the steps in mistral would be a nice option to be able to
rerun easily a particular deployment step from the GUI, versus having
them in ansible which is instead a better option for CLI users ... but
it looks like having them in ansible is the only option which permits us
to reuse the same code to deploy an undercloud because having the steps
in mistral would require the undercloud installation itself to depend on
mistral which we don't want to

James, Dan, please comment on the above if I am wrong
> - It would still be possible to run ansible-playbook directly for
> various use cases (dev/test/POC/demos). This preserves the quick
> iteration via Ansible that is often desired.
> 
> - The remaining SoftwareDeployment resources in tripleo-heat-templates
> need to be supported by config download so that the entire
> configuration can be driven with Ansible, not just the deployment
> steps. The success criteria for this point would be to illustrate
> using an image that does not contain a running os-collect-config.
> 
> - The ceph-ansible implementation done in Pike could be reworked to
> use this model. "config download" could generate playbooks that have
> hooks for calling external playbooks, or those hooks could be
> represented in the templates directly. The result would be the same
> either way though in that Heat would no longer be triggering a
> separate Mistral workflow just for ceph-ansible.

I'd say for ceph-ansible, kubernetes and in general anything else which
needs to run with a standard playbook installed on the undercloud and
not one generated via the heat templates... these "external" services
usually require the inventory file to be in different format, to
describe the hosts to use on a per-service basis, not per-role (and I
mean tripleo roles here, not ansible roles obviously)

About that, we discussed a more long term vision where the playbooks
(static data) needd to describe how to deploy/upgrade a given service is
in a separate repo (like tripleo-apb) and we "compose" from heat the
list of playbooks to be executed based on the roles/enabled services; in
this scenario we'd be much closer to what we had to do for ceph-ansible
and I feel like that might finally allow us merge back the ceph
deployment (or kubernetes deployment) process into the more general
approach driven by tripleo

James, Dan, comments?

> - We will need some centralized log storage for the ansible-playbook
> results and should consider using ARA.
> 
> As it would be a lot of work to eventually make this method the
> default, I don't expect or plan that we will complete all this work in
> Queens. We can however start moving in this direction.
> 
> Specifically, I hope to soon add support to config download for the
> rest of the SoftwareDeployment resources in tripleo-heat-templates as
> that will greatly simplify the undercloud container installer. Doing
> so will illustrate using the ephemeral heat-all process as simply a
> means for generating ansible playbooks.
> 
> I plan to create blueprints this week for Queens and beyond. If you're
> interested in this work, please let me know. I'm open to the idea of
> creating an official squad for this work, but I'm not 

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[James Slagle]

On Mon, Sep 18, 2017 at 12:14 PM, Joshua Harlow  wrote:
> Was there any discussion at the PTG on how the newly released AWX[1] will
> affect tripleo/ansible (will it?) or ara or such? Thoughts there?

I think we'd investigate ARA for ansible log and results storage,
since we'd want to save the output.

As for AWX, there wasn't any significant discussion of which I'm
aware. We already have an API (Mistral).

However, the outputs we will get from Heat with "config download" will
be ansible playbooks. So, I think that leaves the door open for a
variety of eventual solutions that can interface with playbooks
(Mistral, AWX, cli, etc).

I don't imagine we'd do anything prohibitive that would prevent
someone from loading those playbooks into AWX if desired, or using
them directly from the cli. You just wouldn't be going through the
official API.

-- 
-- James Slagle
--

__
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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[David Moreau Simard]

On Mon, Sep 18, 2017 at 2:14 PM, Joshua Harlow  wrote:
> Was there any discussion at the PTG on how the newly released AWX[1] will
> affect tripleo/ansible (will it?) or ara or such? Thoughts there?
>
> [1] https://github.com/ansible/awx

I wasn't at this particular session (wish I could've cloned myself
several times to attend everything) but AWX doesn't change anything as
far as ARA is concerned.
The use cases are different.

One provides things like
ACL/RBAC/authentication/reporting/auditing/running/editing/etc but
also requires memcached, postgres, rabbitmq, a dedicated server and
running your playbooks through it.
The other one provides... reporting and requires 'pip install ara' on
your laptop :)

The folks from Ansible and Tower have reached out to me about
collaborating and talked about integration with AWX/Tower.
I don't know yet what this means and what it will translate to but
I'll have an idea in the next few weeks.

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

__
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

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

[Joshua Harlow]

Was there any discussion at the PTG on how the newly released AWX[1] 
will affect tripleo/ansible (will it?) or ara or such? Thoughts there?


[1] https://github.com/ansible/awx

James Slagle wrote:

On Wednesday at the PTG, TripleO held a session around our current use
of Ansible and how to move forward. I'll summarize the results of the
session. Feel free to add anything I forgot and provide any feedback
or questions.

We discussed the existing uses of Ansible in TripleO and how they
differ in terms of what they do and how they interact with Ansible. I
covered this in a previous email[1], so I'll skip over summarizing
those points again.

I explained a bit about the  "openstack overcloud config download"
approach implemented in Pike by the upgrades squad. This method
no-op's out the deployment steps during the actual Heat stack-update,
then uses the cli to query stack outputs to create actual Ansible
playbooks from those output values. The Undercloud is then used as the
Ansible runner to apply the playbooks to each Overcloud node.

I created a sequence diagram for this method and explained how it
would also work for initial stack deployment[2]:

https://slagle.fedorapeople.org/tripleo-ansible-arch.png

The high level proposal was to move in a direction where we'd use the
config download method for all Heat driven stack operations
(stack-create and stack-update).

We highlighted and discussed several key points about the method shown
in the diagram:

- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.

- It would still be possible to run ansible-playbook directly for
various use cases (dev/test/POC/demos). This preserves the quick
iteration via Ansible that is often desired.

- The remaining SoftwareDeployment resources in tripleo-heat-templates
need to be supported by config download so that the entire
configuration can be driven with Ansible, not just the deployment
steps. The success criteria for this point would be to illustrate
using an image that does not contain a running os-collect-config.

- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.

- We will need some centralized log storage for the ansible-playbook
results and should consider using ARA.

As it would be a lot of work to eventually make this method the
default, I don't expect or plan that we will complete all this work in
Queens. We can however start moving in this direction.

Specifically, I hope to soon add support to config download for the
rest of the SoftwareDeployment resources in tripleo-heat-templates as
that will greatly simplify the undercloud container installer. Doing
so will illustrate using the ephemeral heat-all process as simply a
means for generating ansible playbooks.

I plan to create blueprints this week for Queens and beyond. If you're
interested in this work, please let me know. I'm open to the idea of
creating an official squad for this work, but I'm not sure if it's
needed or not.

As not everyone was able to attend the PTG, please do provide feedback
about this plan as it should still be considered open for discussion.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-July/119405.html
[2] https://slagle.fedorapeople.org/tripleo-ansible-arch.png



__
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-dev] [TripleO] TripleO/Ansible PTG session

[James Slagle]

On Wednesday at the PTG, TripleO held a session around our current use
of Ansible and how to move forward. I'll summarize the results of the
session. Feel free to add anything I forgot and provide any feedback
or questions.

We discussed the existing uses of Ansible in TripleO and how they
differ in terms of what they do and how they interact with Ansible. I
covered this in a previous email[1], so I'll skip over summarizing
those points again.

I explained a bit about the  "openstack overcloud config download"
approach implemented in Pike by the upgrades squad. This method
no-op's out the deployment steps during the actual Heat stack-update,
then uses the cli to query stack outputs to create actual Ansible
playbooks from those output values. The Undercloud is then used as the
Ansible runner to apply the playbooks to each Overcloud node.

I created a sequence diagram for this method and explained how it
would also work for initial stack deployment[2]:

https://slagle.fedorapeople.org/tripleo-ansible-arch.png

The high level proposal was to move in a direction where we'd use the
config download method for all Heat driven stack operations
(stack-create and stack-update).

We highlighted and discussed several key points about the method shown
in the diagram:

- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.

- It would still be possible to run ansible-playbook directly for
various use cases (dev/test/POC/demos). This preserves the quick
iteration via Ansible that is often desired.

- The remaining SoftwareDeployment resources in tripleo-heat-templates
need to be supported by config download so that the entire
configuration can be driven with Ansible, not just the deployment
steps. The success criteria for this point would be to illustrate
using an image that does not contain a running os-collect-config.

- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.

- We will need some centralized log storage for the ansible-playbook
results and should consider using ARA.

As it would be a lot of work to eventually make this method the
default, I don't expect or plan that we will complete all this work in
Queens. We can however start moving in this direction.

Specifically, I hope to soon add support to config download for the
rest of the SoftwareDeployment resources in tripleo-heat-templates as
that will greatly simplify the undercloud container installer. Doing
so will illustrate using the ephemeral heat-all process as simply a
means for generating ansible playbooks.

I plan to create blueprints this week for Queens and beyond. If you're
interested in this work, please let me know. I'm open to the idea of
creating an official squad for this work, but I'm not sure if it's
needed or not.

As not everyone was able to attend the PTG, please do provide feedback
about this plan as it should still be considered open for discussion.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-July/119405.html
[2] https://slagle.fedorapeople.org/tripleo-ansible-arch.png

-- 
-- James Slagle
--

__
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