[OFI] Dynflow orchestration POC draft

Hello,

I'm sending out a Dynflow orchestration draft for proof-of-concept to
start a discussion.

With regards to having it asap I would use:

  1. Dynflow - workflow engine written originally for Katello.
  2. ForemanTasks - Rails engine that adds Dynflow integration with
    Foreman.
  3. Astapor manifests - top level classes configuring OpenStack HA
    hosts. There is top-level puppet class for each role.
  4. Puppetrun - to manually trigger puppet run on Foreman host.

Minimal POC

Minimal POC would be reusing Astapor manifests. There would be dynflow
added to avoid the manual steps between configuring OpenStack hosts
(Controllers then Computes, etc.).

It would start by triggering Dynflow action which would:

  1. provision needed number of hosts in parallel.
  2. configure all-in-on controller using Astapor class.
    • adding the class to the host.
    • triggering puppet run.
  3. configure nova compute hosts using Astapor class. Same sub-steps.
  4. configure additional hosts in right order with neutron, swift, cinder.

(I'll probably start with µ-POC skipping 1. and 4.)

Open questions

  • Is there a simpler way how to trigger puppet run on a given host?
  • From a quick look Astapor modules should work for us, needs to be
    verified.
  • What would you improve?
  • Do you see any compilations?

I'll also send another email describing better solution to support
multiple layouts later this week.

Petr

> - Is there a simpler way how to trigger puppet run on a given host?

We have the following implementations for puppet run:

puppetrun (for puppetrun/kick, deprecated in Puppet 3)

mcollective (uses mco puppet)

puppetssh (run puppet over ssh)

salt (uses salt puppet.run)

customrun (calls a custom command with args)

Make your choice, ssh might be a way.

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

I suggest to use similar way to install foreman as astapor does but we could
migrate it to kafo [1]. This way users don't have to edit script to configure
networking and get nice UI instead.

Also some parts of kafo could be extracted and used to parse astapor modules
to display parameters in wizard. Kafo already parse parameter documentation,
parameter type (if provided in doc) and some other useful stuff. Also it's easy
to add other attributes to documentation. We'd have to use this in foreman-
proxy and make it upload all such information to foreman. This can be added
after first version however, meanwhile we can seed parameters and their
attributes during foreman install and concentrate on wizard UI (depending on
time and resources, not sure who will work on UI part).

[1] https://github.com/theforeman/kafo/

··· On Monday 24 of February 2014 14:54:26 Petr Chalupa wrote: > Hello, > > I'm sending out a Dynflow orchestration draft for proof-of-concept to > start a discussion. > > With regards to having it asap I would use: > > 1. [Dynflow][1] - workflow engine written originally for Katello. > 2. [ForemanTasks][2] - Rails engine that adds Dynflow integration with > Foreman. > 3. [Astapor manifests][3] - top level classes configuring OpenStack HA > hosts. There is [top-level puppet class][4] for each role. > 4. [Puppetrun][5] - to manually trigger puppet run on Foreman host. > > ## Minimal POC > > Minimal POC would be reusing Astapor manifests. There would be dynflow > added to avoid the manual steps between configuring OpenStack hosts > (Controllers then Computes, etc.). > > It would start by triggering Dynflow action which would: > > 1. provision needed number of hosts in parallel. > 2. configure all-in-on controller using Astapor class. > - adding the class to the host. > - triggering puppet run. > 3. configure nova compute hosts using Astapor class. Same sub-steps. > 4. configure additional hosts in right order with neutron, swift, cinder. > > (I'll probably start with µ-POC skipping 1. and 4.) > > ## Open questions > > - Is there a simpler way how to trigger puppet run on a given host? > - From a quick look Astapor modules should work for us, needs to be > verified. > - What would you improve? > - Do you see any compilations? > > [1]: https://github.com/Dynflow/dynflow/ > [2]: https://github.com/inecas/foreman-tasks > [3]: > https://github.com/redhat-openstack/astapor/tree/master/puppet/modules/quick > stack [4]: > https://github.com/redhat-openstack/astapor/blob/master/bin/seeds.rb#L323-L3 > 42 [5]: http://projects.theforeman.org/projects/foreman/wiki/Puppetrun > > I'll also send another email describing better solution to support > multiple layouts later this week. > > Petr


Marek

+1 I've wanted to use kafo to import data into Foreman for ages - but
agreed, it's not the current focus of OFI :slight_smile:

··· On 25 February 2014 08:45, Marek Hulan wrote: > We'd have to use this in foreman- > proxy and make it upload all such information to foreman. This can be added > after first version however

>> - Is there a simpler way how to trigger puppet run on a given host?

Thanks Lukas!

>
> We have the following implementations for puppet run:
>
> # puppetrun (for puppetrun/kick, deprecated in Puppet 3)

Since it's deprecated we should probably avoid it if there is another
simple way.

> # mcollective (uses mco puppet)

This one is probably not that straightforward as other options, see
https://github.com/witlessbird/foreman_mco/blob/master/SETUP.md

> # puppetssh (run puppet over ssh)

Seems best as a best option. Simple setup, ssh is everywhere. One
disadvantage is that it only triggers the puppet run, there is now way
how to wait for the puppet run to finish and see results directly. It
would be a bad thing anyway, smart-proxy process would be blocked.
Dynflow action can solve this by triggering the puppet run via puppetssh
and then polling Foreman API for new Report.

(Dynflow already supports action suspending to be able to pull
effectively without blocking threads. There is also a helper module for
polling itself.)

see Feature #3047: Support puppet run via SSH - Smart Proxy - Foreman
https://github.com/theforeman/foreman/blob/develop/lib/proxy_api/puppet.rb

> # salt (uses salt puppet.run)

Also complicated, needs Saltstack, see

> # customrun (calls a custom command with args)

AFAIK customrun is used internally by puppetssh so there is probably no
reason to use it directly.

>
> Make your choice, ssh might be a way.

TL;DR I agree puppetssh seems the best.

Petr

··· On 24.02.14 22:12, Lukas Zapletal wrote:

> I suggest to use similar way to install foreman as astapor does but we could
> migrate it to kafo 1. This way users don't have to edit script to configure
> networking and get nice UI instead.
>
> Also some parts of kafo could be extracted and used to parse astapor modules
> to display parameters in wizard. Kafo already parse parameter documentation,
> parameter type (if provided in doc) and some other useful stuff. Also it's easy
> to add other attributes to documentation. We'd have to use this in foreman-
> proxy and make it upload all such information to foreman. This can be added
> after first version however, meanwhile we can seed parameters and their
> attributes during foreman install and concentrate on wizard UI (depending on
> time and resources, not sure who will work on UI part).
>
> 1 https://github.com/theforeman/kafo/

+1 for using kafo to install OFI itself

··· On 25.02.14 9:45, Marek Hulan wrote:

On Monday 24 of February 2014 14:54:26 Petr Chalupa wrote:

Hello,

I’m sending out a Dynflow orchestration draft for proof-of-concept to
start a discussion.

With regards to having it asap I would use:

  1. Dynflow - workflow engine written originally for Katello.
  2. ForemanTasks - Rails engine that adds Dynflow integration with
    Foreman.
  3. Astapor manifests - top level classes configuring OpenStack HA
    hosts. There is [top-level puppet class][4] for each role.
  4. [Puppetrun][5] - to manually trigger puppet run on Foreman host.

Minimal POC

Minimal POC would be reusing Astapor manifests. There would be dynflow
added to avoid the manual steps between configuring OpenStack hosts
(Controllers then Computes, etc.).

It would start by triggering Dynflow action which would:

  1. provision needed number of hosts in parallel.
  2. configure all-in-on controller using Astapor class.
    • adding the class to the host.
    • triggering puppet run.
  3. configure nova compute hosts using Astapor class. Same sub-steps.
  4. configure additional hosts in right order with neutron, swift, cinder.

(I’ll probably start with µ-POC skipping 1. and 4.)

Open questions

  • Is there a simpler way how to trigger puppet run on a given host?
  • From a quick look Astapor modules should work for us, needs to be
    verified.
  • What would you improve?
  • Do you see any compilations?

stack [4]:
https://github.com/redhat-openstack/astapor/blob/master/bin/seeds.rb#L323-L3
42 [5]: Puppetrun - Foreman

I’ll also send another email describing better solution to support
multiple layouts later this week.

Petr

>
>> - Is there a simpler way how to trigger puppet run on a given host?
>>>
>>
> Thanks Lukas!
>
>
>
>> We have the following implementations for puppet run:
>>
>> # puppetrun (for puppetrun/kick, deprecated in Puppet 3)
>>
>
> Since it's deprecated we should probably avoid it if there is another
> simple way.
>
>
> # mcollective (uses mco puppet)
>>
>
> This one is probably not that straightforward as other options, see
> https://github.com/witlessbird/foreman_mco/blob/master/SETUP.md
>
>
> # puppetssh (run puppet over ssh)
>>
>
> Seems best as a best option. Simple setup, ssh is everywhere. One
> disadvantage is that it only triggers the puppet run, there is now way how
> to wait for the puppet run to finish and see results directly. It would be
> a bad thing anyway, smart-proxy process would be blocked. Dynflow action
> can solve this by triggering the puppet run via puppetssh and then polling
> Foreman API for new Report.
>

no need to pull, just add a hook on report creation / host update.

Ohad

··· On Tue, Feb 25, 2014 at 10:54 AM, Petr Chalupa wrote: > On 24.02.14 22:12, Lukas Zapletal wrote:

(Dynflow already supports action suspending to be able to pull effectively
without blocking threads. There is also a helper module for polling itself.)

see Feature #3047: Support puppet run via SSH - Smart Proxy - Foreman
https://github.com/theforeman/foreman/blob/develop/lib/proxy_api/puppet.rb

salt (uses salt puppet.run)

Also complicated, needs Saltstack, see https://github.com/theforeman/
smart-proxy/pull/113

customrun (calls a custom command with args)

AFAIK customrun is used internally by puppetssh so there is probably no
reason to use it directly.

Make your choice, ssh might be a way.

TL;DR I agree puppetssh seems the best.

Petr


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

>
>
>
>
>
> - Is there a simpler way how to trigger puppet run on a
> given host?
>
>
> Thanks Lukas!
>
>
>
> We have the following implementations for puppet run:
>
> # puppetrun (for puppetrun/kick, deprecated in Puppet 3)
>
>
> Since it's deprecated we should probably avoid it if there is
> another simple way.
>
>
> # mcollective (uses mco puppet)
>
>
> This one is probably not that straightforward as other options, see
> https://github.com/__witlessbird/foreman_mco/blob/__master/SETUP.md
> <https://github.com/witlessbird/foreman_mco/blob/master/SETUP.md>
>
>
> # puppetssh (run puppet over ssh)
>
>
> Seems best as a best option. Simple setup, ssh is everywhere. One
> disadvantage is that it only triggers the puppet run, there is now
> way how to wait for the puppet run to finish and see results
> directly. It would be a bad thing anyway, smart-proxy process would
> be blocked. Dynflow action can solve this by triggering the puppet
> run via puppetssh and then polling Foreman API for new Report.
>
>
> no need to pull, just add a hook on report creation / host update.
>
> Ohad

Right thanks.

··· On 25.02.14 10:01, Ohad Levy wrote: > On Tue, Feb 25, 2014 at 10:54 AM, Petr Chalupa > wrote: > On 24.02.14 22:12, Lukas Zapletal wrote:
(Dynflow already supports action suspending to be able to pull
effectively without blocking threads. There is also a helper module
for polling itself.)

see http://projects.theforeman.__org/issues/3047
<http://projects.theforeman.org/issues/3047>
https://github.com/theforeman/__foreman/blob/develop/lib/__proxy_api/puppet.rb
<https://github.com/theforeman/foreman/blob/develop/lib/proxy_api/puppet.rb>


    #   salt        (uses salt puppet.run)


Also complicated, needs Saltstack, see
https://github.com/theforeman/__smart-proxy/pull/113
<https://github.com/theforeman/smart-proxy/pull/113>


    #   customrun   (calls a custom command with args)


AFAIK customrun is used internally by puppetssh so there is probably
no reason to use it directly.



    Make your choice, ssh might be a way.


TL;DR I agree puppetssh seems the best.

Petr


--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@__googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/__groups/opt_out
<https://groups.google.com/groups/opt_out>.


You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

> >no need to pull, just add a hook on report creation / host update.
>
> Right thanks.
>

Isn't this too much fragile?

If you will be sshing to the host already, instead puppet kick, you can
literally run the puppet to do the work for you. This can be blocking,
so you will wait until puppet returns to shell with a return code.

Not sure if you'd need to disable puppet agent before doing that.

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman