[OFI] Foreman installer + provisioning setup

[Marek_Hulan]

Hello everyone,

As a part of staypuft project (openstack installer based on foreman in form of
foreman plugin) we created a script that setup foreman instance to be able to
provision other machines easily [1]. It has a lot of hardcoded values since
it's for livecd specific purpose. I'd like to improve that and built it into
foreman-installer. The result should be installer which setups foreman ready
for provisioning machines and which will be usable by most of users (at least
for testing) without any further actions. I'd also like it to be customizable
and completely optional for advanced users.

Staypuft may require other seed data or relations (see below) than vanilla
foreman so some parts should be optional and customizable from outside (either
puppet module or just by adding some files to vanilla foreman-installer, not
editing existing ones)

I think we basically need two new features in installer (kafo):

1. As a developer I want to specify parameter relations and change actions
2. As a developer I want to specify seed data for installed foreman instance

Let's focus on 1. at first. I'd like to be able to setup provisioning just by
specifying NIC. Most of values can be determined based on that and output of
Facter. So e.g. we can setup subnet because we can guess CIDR, dhcp range,
gateway by Facter information about particular NIC. However this mean that one
parameter must be able to set value of other parameters dynamically so when
user selects eth0 he gets different values than for eth1. I'd like to add
support for so called parameter callbacks so you could say "execute this block
when param1.value changes".

For the staypuft effort these parameter callbacks would be defined in Kafo hooks
[2]. Kafo currently support :pre and :post hooks. We just need to extend it so
other installers can register their own hooks (in this case before parameter
values are parsed and set) easily. I think creating directory for hooks
definitions could do the trick, so anyone could add his own kafo hook. This
would also cleanup bin/installer script and could prevent duplication between
foreman and katello installers because existing hooks (e.g. --foreman-reset-
db) would be extracted.

So in this hook we'd define paramater hooks like this (DSL is just an example)

KafoConfigure.register_init do |kafo|

set to static value, not too useful here but may be somewhere else

kafo.param('staypuft/interface').changes('foreman-proxy/dhcp/interface',
'eth0')

set dynamically whenever staypuft/installer value changes

kafo.param('staypuft/interface').changes('foreman-proxy/dhcp/range') {|kafo|
kafo.param('foreman-proxy/dhcp/range').value = …
}
end

Note that we have to add some cycle detection mechanism so when we try to
change some param we don't change it's value again.
This seems very straightforward to me and it should allow us to reuse this to
create even better user experience with other parameters, so one parameter can
modify/set other but user can still go and change those if he needs.

To the second feature. What the staypuft script does is that it uses
foreman_api to set a lot of relations and some default objects. It's basically
seeding but important difference is that seed does not have access to installer
answers. Well it could have been read from answers file if user hadn't deleted
it, but I think it make more sense to leverage installer for this since it's
the same process running under root (we may need to read some system data,
maybe even not present in answers file). Again I'd like to use kafo hooks here.
We can use post hook that will be triggered just after puppet run is done,
which means foreman is up and running (and already seeded by seed.rb).

Later (not needed for staypuft at all) we could add support to define parameter
callbacks into rdoc so they are on the same place with rest of puppet class
'configuration', but it depends on their complexity.

Any feedback would be appreciated. Please let me know if any parts needs more
elaborating.

[1]https://github.com/radez/foreman-live/blob/master/setup_provisioning.rb
[2]https://github.com/theforeman/kafo#hooks

···

-- Marek

[Martyn_Taylor]

> Hello everyone,
>
> As a part of staypuft project (openstack installer based on foreman in form of
> foreman plugin) we created a script that setup foreman instance to be able to
> provision other machines easily [1]. It has a lot of hardcoded values since
> it's for livecd specific purpose. I'd like to improve that and built it into
> foreman-installer.
Awesome stuff! So many people had trouble getting this setup. This
will be a real help.

Can you tell me if this script supports both virsh and BMC setup?
> The result should be installer which setups foreman ready
> for provisioning machines and which will be usable by most of users (at least
> for testing) without any further actions. I'd also like it to be customizable
> and completely optional for advanced users.
>
> Staypuft may require other seed data or relations (see below) than vanilla
> foreman so some parts should be optional and customizable from outside (either
> puppet module

Yes I would also like to see the puppet-ssh configuration as part of the
foreman installer too.

Work has been started on a puppet module to enable the relevant
puppetssh config pieces and to distribute keys here:
https://github.com/mtaylor/puppet-foreman_proxy_puppetssh.

I wonder if we can use this work to add support for this in the
installer itself?
> or just by adding some files to vanilla foreman-installer, not
> editing existing ones)
>
> I think we basically need two new features in installer (kafo):
> 1. As a developer I want to specify parameter relations and change actions
> 2. As a developer I want to specify seed data for installed foreman instance
>
> Let's focus on 1. at first. I'd like to be able to setup provisioning just by
> specifying NIC. Most of values can be determined based on that and output of
> Facter. So e.g. we can setup subnet because we can guess CIDR, dhcp range,
> gateway by Facter information about particular NIC.
Will this work for a VM dev environment?
> However this mean that one
> parameter must be able to set value of other parameters dynamically so when
> user selects eth0 he gets different values than for eth1. I'd like to add
> support for so called parameter callbacks so you could say "execute this block
> when param1.value changes".
>
> For the staypuft effort these parameter callbacks would be defined in Kafo hooks
> [2]. Kafo currently support :pre and :post hooks. We just need to extend it so
> other installers can register their own hooks (in this case before parameter
> values are parsed and set) easily. I think creating directory for hooks
> definitions could do the trick, so anyone could add his own kafo hook. This
> would also cleanup bin/installer script and could prevent duplication between
> foreman and katello installers because existing hooks (e.g. --foreman-reset-
> db) would be extracted.
>
> So in this hook we'd define paramater hooks like this (DSL is just an example)
>
> KafoConfigure.register_init do |kafo|
> # set to static value, not too useful here but may be somewhere else
> kafo.param('staypuft/interface').changes('foreman-proxy/dhcp/interface',
> 'eth0')
>
> # set dynamically whenever staypuft/installer value changes
> kafo.param('staypuft/interface').changes('foreman-proxy/dhcp/range') {|kafo|
> kafo.param('foreman-proxy/dhcp/range').value = …
> }
> end
>
> Note that we have to add some cycle detection mechanism so when we try to
> change some param we don't change it's value again.
> This seems very straightforward to me and it should allow us to reuse this to
> create even better user experience with other parameters, so one parameter can
> modify/set other but user can still go and change those if he needs.
>
> To the second feature. What the staypuft script does is that it uses
> foreman_api to set a lot of relations and some default objects. It's basically
> seeding but important difference is that seed does not have access to installer
> answers. Well it could have been read from answers file if user hadn't deleted
> it, but I think it make more sense to leverage installer for this since it's
> the same process running under root (we may need to read some system data,
> maybe even not present in answers file).
I don't think we need access to the answers file right now (at least for
the Staypuft setup we had in Brno).

But this approach seems sensible to me, it gives us a platform to add in
the bits we need.
> Again I'd like to use kafo hooks here.
> We can use post hook that will be triggered just after puppet run is done,
> which means foreman is up and running (and already seeded by seed.rb).
>
> Later (not needed for staypuft at all) we could add support to define parameter
> callbacks into rdoc so they are on the same place with rest of puppet class
> 'configuration', but it depends on their complexity.
>
> Any feedback would be appreciated. Please let me know if any parts needs more
> elaborating.
Great stuff! Thanks alot!

···

On 25/03/14 16:40, Marek Hulan wrote: > > [1]https://github.com/radez/foreman-live/blob/master/setup_provisioning.rb > [2]https://github.com/theforeman/kafo#hooks >

[Marek_Hulan]

Hi Martyn, I'm sending answers in text below

> > Hello everyone,
> >
> > As a part of staypuft project (openstack installer based on foreman in
> > form of foreman plugin) we created a script that setup foreman instance
> > to be able to provision other machines easily [1]. It has a lot of
> > hardcoded values since it's for livecd specific purpose. I'd like to
> > improve that and built it into foreman-installer.
>
> Awesome stuff! So many people had trouble getting this setup. This
> will be a real help.
>
> Can you tell me if this script supports both virsh and BMC setup?

It should make no difference. What the provisioning setup script does is that
it creates all objects (subnet, domain, assign provisioning temlates, etc)
with default data and wrap that into hostgroup with name 'base'. It's up to
you if you want to provision hosts on libvirt or baremetals, in fact this
script don't install or configure compute resource for you. So if you want to
use libvirt, you must still install it and add it as a compute resource in
foreman, then you can provision host using base hostgroup which sets all
relations accordingly.

>
> > The result should be installer which setups foreman ready
> > for provisioning machines and which will be usable by most of users (at
> > least for testing) without any further actions. I'd also like it to be
> > customizable and completely optional for advanced users.
> >
> > Staypuft may require other seed data or relations (see below) than vanilla
> > foreman so some parts should be optional and customizable from outside
> > (either puppet module
>
> Yes I would also like to see the puppet-ssh configuration as part of the
> foreman installer too.
>
> Work has been started on a puppet module to enable the relevant
> puppetssh config pieces and to distribute keys here:
> https://github.com/mtaylor/puppet-foreman_proxy_puppetssh.
>
> I wonder if we can use this work to add support for this in the
> installer itself?

That looks pretty well. With few modifications I think we could integrate that
into foreman-installer. I created a RFE issue for that at
http://projects.theforeman.org/issues/4865

> > or just by adding some files to vanilla foreman-installer, not
> > editing existing ones)
> >
> > I think we basically need two new features in installer (kafo):
> > 1. As a developer I want to specify parameter relations and change actions
> > 2. As a developer I want to specify seed data for installed foreman
> > instance
> >
> > Let's focus on 1. at first. I'd like to be able to setup provisioning just
> > by specifying NIC. Most of values can be determined based on that and
> > output of Facter. So e.g. we can setup subnet because we can guess CIDR,
> > dhcp range, gateway by Facter information about particular NIC.
>
> Will this work for a VM dev environment?

If you provide it virtual device like virbr0 it can detect CIDR etc as well so
the answer is yes. One issue I can see on this setup is that gateway can't be
detected correctly (virtual hosts shouldn't use gateway of physical host
directly) so this is the case when we should either add more logic to set
correct value or you should set it manually.

Thank you for feedback, feel free to ping me with any other questions.

···

On Wednesday 26 of March 2014 09:22:10 Martyn Taylor wrote: > On 25/03/14 16:40, Marek Hulan wrote:

–
Marek

However this mean that one
parameter must be able to set value of other parameters dynamically so
when
user selects eth0 he gets different values than for eth1. I’d like to add
support for so called parameter callbacks so you could say “execute this
block when param1.value changes”.

For the staypuft effort these parameter callbacks would be defined in Kafo
hooks [2]. Kafo currently support :pre and :post hooks. We just need to
extend it so other installers can register their own hooks (in this case
before parameter values are parsed and set) easily. I think creating
directory for hooks definitions could do the trick, so anyone could add
his own kafo hook. This would also cleanup bin/installer script and could
prevent duplication between foreman and katello installers because
existing hooks (e.g. --foreman-reset- db) would be extracted.

So in this hook we’d define paramater hooks like this (DSL is just an
example)

KafoConfigure.register_init do |kafo|

set to static value, not too useful here but may be somewhere else

kafo.param(‘staypuft/interface’).changes(‘foreman-proxy/dhcp/interface’
,

‘eth0’)

set dynamically whenever staypuft/installer value changes

kafo.param(‘staypuft/interface’).changes(‘foreman-proxy/dhcp/range’)
{|kafo|>
kafo.param(‘foreman-proxy/dhcp/range’).value = …

}

end

Note that we have to add some cycle detection mechanism so when we try to
change some param we don’t change it’s value again.
This seems very straightforward to me and it should allow us to reuse this
to create even better user experience with other parameters, so one
parameter can modify/set other but user can still go and change those if
he needs.

To the second feature. What the staypuft script does is that it uses
foreman_api to set a lot of relations and some default objects. It’s
basically seeding but important difference is that seed does not have
access to installer answers. Well it could have been read from answers
file if user hadn’t deleted it, but I think it make more sense to
leverage installer for this since it’s the same process running under
root (we may need to read some system data, maybe even not present in
answers file).

I don’t think we need access to the answers file right now (at least for
the Staypuft setup we had in Brno).

But this approach seems sensible to me, it gives us a platform to add in
the bits we need.

Again I’d like to use kafo hooks here.
We can use post hook that will be triggered just after puppet run is done,
which means foreman is up and running (and already seeded by seed.rb).

Later (not needed for staypuft at all) we could add support to define
parameter callbacks into rdoc so they are on the same place with rest of
puppet class ‘configuration’, but it depends on their complexity.

Any feedback would be appreciated. Please let me know if any parts needs
more elaborating.

Great stuff! Thanks alot!

[1]https://github.com/radez/foreman-live/blob/master/setup_provisioning.rb
[2]https://github.com/theforeman/kafo#hooks

[Marek_Hulan]

Hello

I spent some time on discussing installer part with Petr and I'm sending my
updated thoughts about how to proceed with installer for staypuft.

TL;DR: parameter hooks are great, we won't use them, we'll create staypuft-
installer as fork of foreman-installer

I'd like to elaborate the hooks implementation a bit more. Basically I heard
one type of concern - why should we introduce hooking mechanism to add
relations between puppet parameters in ruby if we can create a wrapping class.
The answer is that with wrapping class you hardcode classes and their
parameter values and disable further customization of underlaying classes.
Basically you put the wrapping class on top of other classes and disallow user
to use their full potential. And for every installation layout you either have
to create a new wrapping class or add some conditions to it so you're making
the usage of class harder again.

By introducing hooks we should be able to create a new class which lives on
the same level as all others making it possible to use both. Imagine we have
our foreman classes (foreman, foreman-proxy, puppet). Users that don't
understand all details of these 3 classes could use newly created (easy-
install) class which would set values of foreman classes for them. All four
classes would be used in fact and easy-install just defines new parameters used
as triggers for hooks. Advanced users could still customize values of foreman
classes so they are not limited only to what wrapping class would allow them.

Also hooks could be reused when user decides not to install foreman-proxy and
puppet. He just disables them and he should be still able to us easy-install
which configures foreman. Then he could enable the rest and run kafo in noop
mode so he gets answers file that he can use on other machine to install proxy
and puppet.

We could also import these hooks into foreman so that they would be able to
set values in host or hostgroup parameters form. So if user have foreman class
assigned and assigns easy-install it will help him to override correct
parameters. This is more distant future feature and could involve foreman form
modifications but I think it should be possible in general.

However the most important question is - do we need it now? And the answer is
definitely not for first staypuft version. We'll do the similar thing - we'll
use kafo hooks (not parameter but installer hooks) to ask user for some values
then we'll do the magic and we'll predefine the answer file. Then after
installation is done we'll do the seeding again using kafo hook. I'd prefer
kafo hook because we would be able to use logger, colors and other goodies
that kafo already provides.

So the most important outcome of this is that we'll need own staypuft-
installer because this is impossible to get in foreman-installer as is. It
should be simple fork with one or more files attached.

Any feedback is highly appreciated

···

-- Marek On Wednesday 26 of March 2014 12:31:58 Marek Hulan wrote: > Hi Martyn, I'm sending answers in text below > > On Wednesday 26 of March 2014 09:22:10 Martyn Taylor wrote: > > On 25/03/14 16:40, Marek Hulan wrote: > > > Hello everyone, > > > > > > As a part of staypuft project (openstack installer based on foreman in > > > form of foreman plugin) we created a script that setup foreman instance > > > to be able to provision other machines easily [1]. It has a lot of > > > hardcoded values since it's for livecd specific purpose. I'd like to > > > improve that and built it into foreman-installer. > > > > Awesome stuff! So many people had trouble getting this setup. This > > will be a real help. > > > > Can you tell me if this script supports both virsh and BMC setup? > > It should make no difference. What the provisioning setup script does is > that it creates all objects (subnet, domain, assign provisioning temlates, > etc) with default data and wrap that into hostgroup with name 'base'. It's > up to you if you want to provision hosts on libvirt or baremetals, in fact > this script don't install or configure compute resource for you. So if you > want to use libvirt, you must still install it and add it as a compute > resource in foreman, then you can provision host using base hostgroup which > sets all relations accordingly. > > > > The result should be installer which setups foreman ready > > > for provisioning machines and which will be usable by most of users (at > > > least for testing) without any further actions. I'd also like it to be > > > customizable and completely optional for advanced users. > > > > > > Staypuft may require other seed data or relations (see below) than > > > vanilla > > > foreman so some parts should be optional and customizable from outside > > > (either puppet module > > > > Yes I would also like to see the puppet-ssh configuration as part of the > > foreman installer too. > > > > Work has been started on a puppet module to enable the relevant > > puppetssh config pieces and to distribute keys here: > > https://github.com/mtaylor/puppet-foreman_proxy_puppetssh. > > > > I wonder if we can use this work to add support for this in the > > installer itself? > > That looks pretty well. With few modifications I think we could integrate > that into foreman-installer. I created a RFE issue for that at > http://projects.theforeman.org/issues/4865 > > > > or just by adding some files to vanilla foreman-installer, not > > > editing existing ones) > > > > > > I think we basically need two new features in installer (kafo): > > > 1. As a developer I want to specify parameter relations and change > > > actions > > > 2. As a developer I want to specify seed data for installed foreman > > > instance > > > > > > Let's focus on 1. at first. I'd like to be able to setup provisioning > > > just > > > by specifying NIC. Most of values can be determined based on that and > > > output of Facter. So e.g. we can setup subnet because we can guess CIDR, > > > dhcp range, gateway by Facter information about particular NIC. > > > > Will this work for a VM dev environment? > > If you provide it virtual device like virbr0 it can detect CIDR etc as well > so the answer is yes. One issue I can see on this setup is that gateway > can't be detected correctly (virtual hosts shouldn't use gateway of > physical host directly) so this is the case when we should either add more > logic to set correct value or you should set it manually. > > Thank you for feedback, feel free to ping me with any other questions. > > > > However this mean that one > > > parameter must be able to set value of other parameters dynamically so > > > when > > > user selects eth0 he gets different values than for eth1. I'd like to > > > add > > > support for so called parameter callbacks so you could say "execute this > > > block when param1.value changes". > > > > > > For the staypuft effort these parameter callbacks would be defined in > > > Kafo > > > hooks [2]. Kafo currently support :pre and :post hooks. We just need to > > > extend it so other installers can register their own hooks (in this case > > > before parameter values are parsed and set) easily. I think creating > > > directory for hooks definitions could do the trick, so anyone could add > > > his own kafo hook. This would also cleanup bin/installer script and > > > could > > > prevent duplication between foreman and katello installers because > > > existing hooks (e.g. --foreman-reset- db) would be extracted. > > > > > > So in this hook we'd define paramater hooks like this (DSL is just an > > > example) > > > > > > KafoConfigure.register_init do |kafo| > > > > > > # set to static value, not too useful here but may be somewhere else > > > kafo.param('staypuft/interface').changes('foreman-proxy/dhcp/interfac > > > e' > > > , > > > > > > 'eth0') > > > > > > # set dynamically whenever staypuft/installer value changes > > > kafo.param('staypuft/interface').changes('foreman-proxy/dhcp/range') > > > {|kafo|> > > > > > > kafo.param('foreman-proxy/dhcp/range').value = ... > > > > > > } > > > > > > end > > > > > > Note that we have to add some cycle detection mechanism so when we try > > > to > > > change some param we don't change it's value again. > > > This seems very straightforward to me and it should allow us to reuse > > > this > > > to create even better user experience with other parameters, so one > > > parameter can modify/set other but user can still go and change those if > > > he needs. > > > > > > To the second feature. What the staypuft script does is that it uses > > > foreman_api to set a lot of relations and some default objects. It's > > > basically seeding but important difference is that seed does not have > > > access to installer answers. Well it could have been read from answers > > > file if user hadn't deleted it, but I think it make more sense to > > > leverage installer for this since it's the same process running under > > > root (we may need to read some system data, maybe even not present in > > > answers file). > > > > I don't think we need access to the answers file right now (at least for > > the Staypuft setup we had in Brno). > > > > But this approach seems sensible to me, it gives us a platform to add in > > the bits we need. > > > > > Again I'd like to use kafo hooks here. > > > We can use post hook that will be triggered just after puppet run is > > > done, > > > which means foreman is up and running (and already seeded by seed.rb). > > > > > > Later (not needed for staypuft at all) we could add support to define > > > parameter callbacks into rdoc so they are on the same place with rest of > > > puppet class 'configuration', but it depends on their complexity. > > > > > > Any feedback would be appreciated. Please let me know if any parts needs > > > more elaborating. > > > > Great stuff! Thanks alot! > > > > > [1]https://github.com/radez/foreman-live/blob/master/setup_provisioning. > > > rb > > > [2]https://github.com/theforeman/kafo#hooks

[Bryan_Kearney]

I assume over time I will be able to use staypuft with a normal foreman
install?
– bk

···

On 03/28/2014 06:10 AM, Marek Hulan wrote: > Hello > > I spent some time on discussing installer part with Petr and I'm sending my > updated thoughts about how to proceed with installer for staypuft. > > TL;DR: parameter hooks are great, we won't use them, we'll create staypuft- > installer as fork of foreman-installer > > I'd like to elaborate the hooks implementation a bit more. Basically I heard > one type of concern - why should we introduce hooking mechanism to add > relations between puppet parameters in ruby if we can create a wrapping class. > The answer is that with wrapping class you hardcode classes and their > parameter values and disable further customization of underlaying classes. > Basically you put the wrapping class on top of other classes and disallow user > to use their full potential. And for every installation layout you either have > to create a new wrapping class or add some conditions to it so you're making > the usage of class harder again. > > By introducing hooks we should be able to create a new class which lives on > the same level as all others making it possible to use both. Imagine we have > our foreman classes (foreman, foreman-proxy, puppet). Users that don't > understand all details of these 3 classes could use newly created (easy- > install) class which would set values of foreman classes for them. All four > classes would be used in fact and easy-install just defines new parameters used > as triggers for hooks. Advanced users could still customize values of foreman > classes so they are not limited only to what wrapping class would allow them. > > Also hooks could be reused when user decides not to install foreman-proxy and > puppet. He just disables them and he should be still able to us easy-install > which configures foreman. Then he could enable the rest and run kafo in noop > mode so he gets answers file that he can use on other machine to install proxy > and puppet. > > We could also import these hooks into foreman so that they would be able to > set values in host or hostgroup parameters form. So if user have foreman class > assigned and assigns easy-install it will help him to override correct > parameters. This is more distant future feature and could involve foreman form > modifications but I think it should be possible in general. > > However the most important question is - do we need it now? And the answer is > definitely not for first staypuft version. We'll do the similar thing - we'll > use kafo hooks (not parameter but installer hooks) to ask user for some values > then we'll do the magic and we'll predefine the answer file. Then after > installation is done we'll do the seeding again using kafo hook. I'd prefer > kafo hook because we would be able to use logger, colors and other goodies > that kafo already provides. > > So the most important outcome of this is that we'll need own staypuft- > installer because this is impossible to get in foreman-installer as is. It > should be simple fork with one or more files attached. > > Any feedback is highly appreciated >

[Marek_Hulan]

Yes, it would be possible, although I'm not sure whether all users would
appreciate that built-in.

···

-- Marek

On Friday 28 of March 2014 08:06:39 Bryan Kearney wrote:

I assume over time I will be able to use staypuft with a normal foreman
install?
– bk

On 03/28/2014 06:10 AM, Marek Hulan wrote:

Hello

I spent some time on discussing installer part with Petr and I’m sending
my
updated thoughts about how to proceed with installer for staypuft.

TL;DR: parameter hooks are great, we won’t use them, we’ll create
staypuft-
installer as fork of foreman-installer

I’d like to elaborate the hooks implementation a bit more. Basically I
heard one type of concern - why should we introduce hooking mechanism to
add relations between puppet parameters in ruby if we can create a
wrapping class. The answer is that with wrapping class you hardcode
classes and their parameter values and disable further customization of
underlaying classes. Basically you put the wrapping class on top of other
classes and disallow user to use their full potential. And for every
installation layout you either have to create a new wrapping class or add
some conditions to it so you’re making the usage of class harder again.

By introducing hooks we should be able to create a new class which lives
on
the same level as all others making it possible to use both. Imagine we
have our foreman classes (foreman, foreman-proxy, puppet). Users that
don’t understand all details of these 3 classes could use newly created
(easy- install) class which would set values of foreman classes for them.
All four classes would be used in fact and easy-install just defines new
parameters used as triggers for hooks. Advanced users could still
customize values of foreman classes so they are not limited only to what
wrapping class would allow them.

Also hooks could be reused when user decides not to install foreman-proxy
and puppet. He just disables them and he should be still able to us
easy-install which configures foreman. Then he could enable the rest and
run kafo in noop mode so he gets answers file that he can use on other
machine to install proxy and puppet.

We could also import these hooks into foreman so that they would be able
to
set values in host or hostgroup parameters form. So if user have foreman
class assigned and assigns easy-install it will help him to override
correct parameters. This is more distant future feature and could involve
foreman form modifications but I think it should be possible in general.

However the most important question is - do we need it now? And the answer
is definitely not for first staypuft version. We’ll do the similar thing

• we’ll use kafo hooks (not parameter but installer hooks) to ask user
  for some values then we’ll do the magic and we’ll predefine the answer
  file. Then after installation is done we’ll do the seeding again using
  kafo hook. I’d prefer kafo hook because we would be able to use logger,
  colors and other goodies that kafo already provides.

So the most important outcome of this is that we’ll need own staypuft-
installer because this is impossible to get in foreman-installer as is. It
should be simple fork with one or more files attached.

Any feedback is highly appreciated

[Bryan_Kearney]

No… I am assuming a "Install this plugin if you want a great OpenStack
experience" and then a "Install this plugin if you want a great oVirt
experience" and then a "Install this experience if you want a great
XXXXX experience"

– bk

···

On 03/28/2014 08:50 AM, Marek Hulan wrote: > Yes, it would be possible, although I'm not sure whether all users would > appreciate that built-in. >

[Marek_Hulan]

Ah, yes, that's the plan. Sorry it took me a while

···

-- Marek

On Friday 28 of March 2014 08:52:12 Bryan Kearney wrote:

On 03/28/2014 08:50 AM, Marek Hulan wrote:

Yes, it would be possible, although I’m not sure whether all users would
appreciate that built-in.

No… I am assuming a “Install this plugin if you want a great OpenStack
experience” and then a “Install this plugin if you want a great oVirt
experience” and then a “Install this experience if you want a great
XXXXX experience”

– bk