This sprint the Katello team is starting to look at how to deploy Katello
as an engine using the Foreman installer. Unlike other plugins, Katello
brings along a number of dependencies such as Pulp and Candlepin that must
be setup and maintained as part of the installation process. After a few
brief discussions with some developers, it seemed logical to open this up
for discussion to get the best idea of what approach to take. The
suggestions I have encountered thus far:
Include all the necessary installer pieces for Katello directly into
Foreman installer
Add some way to plugin to the installer
Build something on top of the Foreman installer + Katello bits to be
used for installing Foreman+Katello
I assumed using kafo, hammer, and foreman there would be three places
for plugins. So if $AN_ENGINE wants to be more first clas, meaning it
has a cli and is installed… then it would add modules to kafo, and
plugins to hammer.
If we want a friendly wrapper rpm (Content + Provisioning) that pulls in
the above, that seems fine.
– bk
···
On 11/26/2013 08:51 AM, Eric D Helms wrote:
> Howdy,
>
> This sprint the Katello team is starting to look at how to deploy
> Katello as an engine using the Foreman installer. Unlike other plugins,
> Katello brings along a number of dependencies such as Pulp and Candlepin
> that must be setup and maintained as part of the installation process.
> After a few brief discussions with some developers, it seemed logical to
> open this up for discussion to get the best idea of what approach to
> take. The suggestions I have encountered thus far:
>
> 1) Include all the necessary installer pieces for Katello directly into
> Foreman installer
> 2) Add some way to plugin to the installer
> 3) Build something on top of the Foreman installer + Katello bits to be
> used for installing Foreman+Katello
>
> Howdy,
>
> This sprint the Katello team is starting to look at how to deploy Katello
> as an engine using the Foreman installer. Unlike other plugins, Katello
> brings along a number of dependencies such as Pulp and Candlepin that must
> be setup and maintained as part of the installation process. After a few
> brief discussions with some developers, it seemed logical to open this up
> for discussion to get the best idea of what approach to take. The
> suggestions I have encountered thus far:
>
> 1) Include all the necessary installer pieces for Katello directly into
> Foreman installer
> 2) Add some way to plugin to the installer
> 3) Build something on top of the Foreman installer + Katello bits to be
> used for installing Foreman+Katello
>
>
> Thoughts?
Hello
Kafo was built just for this I think we should do option 4) (or slightly
modified 3) Since foreman-installer is just wrapping script + puppet modules
for foreman and dependencies, I think we should create a new installer where
most of logic is shared (in kafo gem) and we should just add more puppet
modules.
Also we could change documentation of puppet modules a bit so users aren't
overwhelmed by hundreds of parameters to configure and things like that…
What was said, foreman-installer is ready, Ivan already converted some
(most?) puppet classes to parametrized classes which is the most obvious
requirement to get this working.
One thing I see here is that Foreman upstream does support Debians too
but Katello puppet modules are not ready for this I guess.
> > Howdy,
> >
> > This sprint the Katello team is starting to look at how to deploy Katello
> > as an engine using the Foreman installer. Unlike other plugins, Katello
> > brings along a number of dependencies such as Pulp and Candlepin that must
> > be setup and maintained as part of the installation process. After a few
> > brief discussions with some developers, it seemed logical to open this up
> > for discussion to get the best idea of what approach to take. The
> > suggestions I have encountered thus far:
> >
> > 1) Include all the necessary installer pieces for Katello directly into
> > Foreman installer
> > 2) Add some way to plugin to the installer
> > 3) Build something on top of the Foreman installer + Katello bits to be
> > used for installing Foreman+Katello
> >
> >
> > Thoughts?
>
> Hello
>
> Kafo was built just for this I think we should do option 4) (or slightly
> modified 3) Since foreman-installer is just wrapping script + puppet modules
> for foreman and dependencies, I think we should create a new installer where
> most of logic is shared (in kafo gem) and we should just add more puppet
> modules.
+1, I think node-installer could just envolve to this, as it already uses
reuses bunch of foreman-installer modules + adds more.
– Ivan
···
----- Original Message -----
Also we could change documentation of puppet modules a bit so users aren’t
overwhelmed by hundreds of parameters to configure and things like that…
I think mostly a puppet-katello or puppet-foreman-katello module should
be created which ensures everything is installed. It can use other
modules for this as well (puppet-pulp and puppet-candlepin could be
great modules).
Not sure where we ensure foreman is also installed, but I think in you
want an include foreman (equivalent) somewhere. Possibly Kafo can detect
this.
An alternative could be to include katello as a class inside
puppet-foreman if puppet-foreman-katello would be too small, but somehow
I doubt that.
···
On Tue, Nov 26, 2013 at 05:40:44PM +0100, Marek Hulan wrote:
> > Howdy,
> >
> > This sprint the Katello team is starting to look at how to deploy Katello
> > as an engine using the Foreman installer. Unlike other plugins, Katello
> > brings along a number of dependencies such as Pulp and Candlepin that must
> > be setup and maintained as part of the installation process. After a few
> > brief discussions with some developers, it seemed logical to open this up
> > for discussion to get the best idea of what approach to take. The
> > suggestions I have encountered thus far:
> >
> > 1) Include all the necessary installer pieces for Katello directly into
> > Foreman installer
> > 2) Add some way to plugin to the installer
> > 3) Build something on top of the Foreman installer + Katello bits to be
> > used for installing Foreman+Katello
>
> Kafo was built just for this :-) I think we should do option 4) (or slightly
> modified 3) Since foreman-installer is just wrapping script + puppet modules
> for foreman and dependencies, I think we should create a new installer where
> most of logic is shared (in kafo gem) and we should just add more puppet
> modules.
> What was said, foreman-installer is ready, Ivan already converted some
> (most?) puppet classes to parametrized classes which is the most obvious
> requirement to get this working.
>
> One thing I see here is that Foreman upstream does support Debians too
> but Katello puppet modules are not ready for this I guess.
It's not. And until Pulp supports Debian packages (or at least runs on Debian
to sync Puppet content) it makes little sense to try to cover it from the beginning.
Agreed, but that's no blocker. I see a foreman-katello-installer package
which pulls in more puppet modules than foreman-installer, but otherwise
functions the same way, through Kafo. We just won't package that for Debian
until such time as it makes sense.
···
On 27 November 2013 08:32, Ivan Necas wrote:
----- Original Message -----
What was said, foreman-installer is ready, Ivan already converted some
(most?) puppet classes to parametrized classes which is the most obvious
requirement to get this working.
One thing I see here is that Foreman upstream does support Debians too
but Katello puppet modules are not ready for this I guess.
It’s not. And until Pulp supports Debian packages (or at least runs on
Debian
to sync Puppet content) it makes little sense to try to cover it from the
beginning.
From reading the above, I got two approaches out of the discussion:
Create a new kafo based installer that includes the modules in the
foreman-installer + modules needed for Katello to serve as the installer
for Foreman + Katello to be owned and maintained by the team actively
working on Katello.
Keep foreman-installer as is and Katello will keep a repository of extra
modules that are laid down at RPM installation time so that the kafo-based
foreman-installer can handle installation of Foreman + Katello.
If I have misrepresented either of the above options please let me know.
Also, please let indicate which of the above options people lean towards as
the final solution.
Thanks,
Eric
···
On Thu, Nov 28, 2013 at 7:39 AM, Greg Sutcliffe wrote:
What was said, foreman-installer is ready, Ivan already converted some
(most?) puppet classes to parametrized classes which is the most obvious
requirement to get this working.
One thing I see here is that Foreman upstream does support Debians too
but Katello puppet modules are not ready for this I guess.
It’s not. And until Pulp supports Debian packages (or at least runs on
Debian
to sync Puppet content) it makes little sense to try to cover it from the
beginning.
Agreed, but that’s no blocker. I see a foreman-katello-installer package
which pulls in more puppet modules than foreman-installer, but otherwise
functions the same way, through Kafo. We just won’t package that for Debian
until such time as it makes sense.
I assumed the model would be (2). I had not considered (1) TBH.
– bk
···
On 12/02/2013 06:55 PM, Eric D Helms wrote:
> Howdy,
>
> From reading the above, I got two approaches out of the discussion:
>
> 1) Create a new kafo based installer that includes the modules in the
> foreman-installer + modules needed for Katello to serve as the installer
> for Foreman + Katello to be owned and maintained by the team actively
> working on Katello.
>
> 2) Keep foreman-installer as is and Katello will keep a repository of
> extra modules that are laid down at RPM installation time so that the
> kafo-based foreman-installer can handle installation of Foreman + Katello.
>
> If I have misrepresented either of the above options please let me know.
> Also, please let indicate which of the above options people lean towards
> as the final solution.
I like the 1) more. It's not just about modules but the default answer file,
that will be different for both variants. Katello may define other check scripts
(e.g. checking current version of java). Also README and man pages will be
different.
If I understand 2) correctly this all would have to be modified during
packaging process based on what version do we build. Or would we have another
RPM that would overwrite answer file etc?
···
On Monday 02 of December 2013 21:02:07 Bryan Kearney wrote:
> On 12/02/2013 06:55 PM, Eric D Helms wrote:
> > Howdy,
> >
> > From reading the above, I got two approaches out of the discussion:
> > 1) Create a new kafo based installer that includes the modules in the
> > foreman-installer + modules needed for Katello to serve as the installer
> > for Foreman + Katello to be owned and maintained by the team actively
> > working on Katello.
> >
> > 2) Keep foreman-installer as is and Katello will keep a repository of
> > extra modules that are laid down at RPM installation time so that the
> > kafo-based foreman-installer can handle installation of Foreman + Katello.
> >
> > If I have misrepresented either of the above options please let me know.
> > Also, please let indicate which of the above options people lean towards
> > as the final solution.
>
> I assumed the model would be (2). I had not considered (1) TBH.
>
> -- bk
> > > Howdy,
> > >
> > > From reading the above, I got two approaches out of the discussion:
> > > 1) Create a new kafo based installer that includes the modules in the
> > > foreman-installer + modules needed for Katello to serve as the installer
> > > for Foreman + Katello to be owned and maintained by the team actively
> > > working on Katello.
+1
···
----- Original Message -----
> On Monday 02 of December 2013 21:02:07 Bryan Kearney wrote:
> > On 12/02/2013 06:55 PM, Eric D Helms wrote:
Keep foreman-installer as is and Katello will keep a repository of
extra modules that are laid down at RPM installation time so that the
kafo-based foreman-installer can handle installation of Foreman +
Katello.
If I have misrepresented either of the above options please let me know.
Also, please let indicate which of the above options people lean towards
as the final solution.
I assumed the model would be (2). I had not considered (1) TBH.
– bk
I like the 1) more. It’s not just about modules but the default answer file,
that will be different for both variants. Katello may define other check
scripts
(e.g. checking current version of java). Also README and man pages will be
different.
If I understand 2) correctly this all would have to be modified during
packaging process based on what version do we build. Or would we have another
RPM that would overwrite answer file etc?
A clarification question I overlooked when initially thinking about this
process. Is our expectation that:
a) a user would install Foreman and then install Katello as part of or
after the installation of Foreman using either additions to the
foreman-installer or a katello-installer that assumes the presence of
Foreman/foreman-installer
or
b) a user would install Foreman+Katello using an autonomous installer for
the purpose of installing the two simultaneously?
My initial assumption had been that people were expressing the route to be
(b). However, b) limits the ability to add Katello to an already existing
Foreman installation.
-Eric
···
On Tue, Dec 3, 2013 at 4:04 AM, Ivan Necas wrote:
----- Original Message -----
On Monday 02 of December 2013 21:02:07 Bryan Kearney wrote:
On 12/02/2013 06:55 PM, Eric D Helms wrote:
Howdy,
From reading the above, I got two approaches out of the discussion:
Create a new kafo based installer that includes the modules in the
foreman-installer + modules needed for Katello to serve as the
installer
for Foreman + Katello to be owned and maintained by the team actively
working on Katello.
+1
Keep foreman-installer as is and Katello will keep a repository of
extra modules that are laid down at RPM installation time so that the
kafo-based foreman-installer can handle installation of Foreman +
Katello.
If I have misrepresented either of the above options please let me
know.
Also, please let indicate which of the above options people lean
towards
as the final solution.
I assumed the model would be (2). I had not considered (1) TBH.
– bk
I like the 1) more. It’s not just about modules but the default answer
file,
that will be different for both variants. Katello may define other check
scripts
(e.g. checking current version of java). Also README and man pages will
be
different.
If I understand 2) correctly this all would have to be modified during
packaging process based on what version do we build. Or would we have
another
RPM that would overwrite answer file etc?
> A clarification question I overlooked when initially thinking about this
> process. Is our expectation that:
>
> a) a user would install Foreman and then install Katello as part of or
> after the installation of Foreman using either additions to the
> foreman-installer or a katello-installer that assumes the presence of
> Foreman/foreman-installer
>
> or
>
> b) a user would install Foreman+Katello using an autonomous installer for
> the purpose of installing the two simultaneously?
>
> My initial assumption had been that people were expressing the route to be
> (b). However, b) limits the ability to add Katello to an already existing
> Foreman installation.
I think (b) was the plan. Also since we'd use the same modules for Foreman
part you should be able to run Foreman+Katello installer on system where
Foreman was already installed by "pure" Foreman installer and in such case it
should just add what's missing. It may reconfigure existing Foreman however.
Maybe we could add some detection of "pure" Foreman answer file if this is a
problem.
···
On Wednesday 04 of December 2013 15:51:50 Eric D Helms wrote:
On Monday 02 of December 2013 21:02:07 Bryan Kearney wrote:
On 12/02/2013 06:55 PM, Eric D Helms wrote:
Howdy,
From reading the above, I got two approaches out of the discussion:
Create a new kafo based installer that includes the modules in
the
foreman-installer + modules needed for Katello to serve as the
installer
for Foreman + Katello to be owned and maintained by the team
actively
working on Katello.
+1
Keep foreman-installer as is and Katello will keep a repository
of
extra modules that are laid down at RPM installation time so that
the
kafo-based foreman-installer can handle installation of Foreman +
Katello.
If I have misrepresented either of the above options please let me
know.
Also, please let indicate which of the above options people lean
towards
as the final solution.
I assumed the model would be (2). I had not considered (1) TBH.
– bk
I like the 1) more. It’s not just about modules but the default answer
file,
that will be different for both variants. Katello may define other check
scripts
(e.g. checking current version of java). Also README and man pages will
be
different.
If I understand 2) correctly this all would have to be modified during
packaging process based on what version do we build. Or would we have
···
On 12/05/2013 02:53 AM, Marek Hulan wrote:
> On Wednesday 04 of December 2013 15:51:50 Eric D Helms wrote:
>> >A clarification question I overlooked when initially thinking about this
>> >process. Is our expectation that:
>> >
>> >a) a user would install Foreman and then install Katello as part of or
>> >after the installation of Foreman using either additions to the
>> >foreman-installer or a katello-installer that assumes the presence of
>> >Foreman/foreman-installer
>> >
>> >or
>> >
>> >b) a user would install Foreman+Katello using an autonomous installer for
>> >the purpose of installing the two simultaneously?
>> >
>> >My initial assumption had been that people were expressing the route to be
>> >(b). However, b) limits the ability to add Katello to an already existing
>> >Foreman installation.
> I think (b) was the plan. Also since we'd use the same modules for Foreman
> part you should be able to run Foreman+Katello installer on system where
> Foreman was already installed by "pure" Foreman installer and in such case it
> should just add what's missing. It may reconfigure existing Foreman however.
> Maybe we could add some detection of "pure" Foreman answer file if this is a
> problem.
>
>> >
>
>>
>>> >A clarification question I overlooked when initially thinking about this
>>> >process. Is our expectation that:
>>> >
>>> >a) a user would install Foreman and then install Katello as part of or
>>> >after the installation of Foreman using either additions to the
>>> >foreman-installer or a katello-installer that assumes the presence of
>>> >Foreman/foreman-installer
>>> >
>>> >or
>>> >
>>> >b) a user would install Foreman+Katello using an autonomous installer
>>> for
>>> >the purpose of installing the two simultaneously?
>>> >
>>> >My initial assumption had been that people were expressing the route to
>>> be
>>> >(b). However, b) limits the ability to add Katello to an already
>>> existing
>>> >Foreman installation.
>>>
>> I think (b) was the plan. Also since we'd use the same modules for Foreman
>> part you should be able to run Foreman+Katello installer on system where
>> Foreman was already installed by "pure" Foreman installer and in such
>> case it
>> should just add what's missing. It may reconfigure existing Foreman
>> however.
>> Maybe we could add some detection of "pure" Foreman answer file if this
>> is a
>> problem.
>>
>> >
>>>
>> Lets start with (b), and work back to (a).
This is a generic question about plugins, and how they get installed.
I would assume our installer should know how to install a foreman plugin.
Assuming that each plugin might require additional manifest code, it should
be possible to add more puppet classes.
Do we have any existing hooks for that? e.g. when we generate the
foreman-installer, can it be extended in a way to include other_modules.d
from another repository ?
Ohad.
···
On Thu, Dec 5, 2013 at 2:24 PM, Bryan Kearney wrote:
> On 12/05/2013 02:53 AM, Marek Hulan wrote:
>> On Wednesday 04 of December 2013 15:51:50 Eric D Helms wrote:
Maybe we can create a define foreman::plugin (similar to
apache::mod1), possibly with built in such as foreman::plugin::content
(similar to apache::mod2 with apache::mod::passenger3) or
foreman::plugin::discovery. Then a katello module would have a fixed
point where they can hook into and be sure that foreman is installed.
One could even try to make it foreman::plugin::katello which ensures
the configurations all point to the correct locations (think pulp
server) and rely on the user to ensure the resources are there. That can
be achieved by enabling the pulp module as well.
This is all based on how I as a module writer would prefer it, but I
don't know how katello is packaged or installed as a plugin so it may
not work. One benefit is that it becomes trivial for us to also support
other packaged plugins.
···
On Thu, Dec 05, 2013 at 03:40:31PM +0200, Ohad Levy wrote:
> On Thu, Dec 5, 2013 at 2:24 PM, Bryan Kearney wrote:
>
> > On 12/05/2013 02:53 AM, Marek Hulan wrote:
> >
> >> On Wednesday 04 of December 2013 15:51:50 Eric D Helms wrote:
> >>
> >>> >A clarification question I overlooked when initially thinking about this
> >>> >process. Is our expectation that:
> >>> >
> >>> >a) a user would install Foreman and then install Katello as part of or
> >>> >after the installation of Foreman using either additions to the
> >>> >foreman-installer or a katello-installer that assumes the presence of
> >>> >Foreman/foreman-installer
> >>> >
> >>> >or
> >>> >
> >>> >b) a user would install Foreman+Katello using an autonomous installer
> >>> for
> >>> >the purpose of installing the two simultaneously?
> >>> >
> >>> >My initial assumption had been that people were expressing the route to
> >>> be
> >>> >(b). However, b) limits the ability to add Katello to an already
> >>> existing
> >>> >Foreman installation.
> >>>
> >> I think (b) was the plan. Also since we'd use the same modules for Foreman
> >> part you should be able to run Foreman+Katello installer on system where
> >> Foreman was already installed by "pure" Foreman installer and in such
> >> case it
> >> should just add what's missing. It may reconfigure existing Foreman
> >> however.
> >> Maybe we could add some detection of "pure" Foreman answer file if this
> >> is a
> >> problem.
> >>
> >> >
> >>>
> >> Lets start with (b), and work back to (a).
>
>
> This is a generic question about plugins, and how they get installed.
>
> I would assume our installer should know how to install a foreman plugin.
>
> Assuming that each plugin might require additional manifest code, it should
> be possible to add more puppet classes.
>
> Do we have any existing hooks for that? e.g. when we generate the
> foreman-installer, can it be extended in a way to include other_modules.d
> from another repository ?
> >>> >A clarification question I overlooked when initially thinking about
> >>> >this
> >>> >process. Is our expectation that:
> >>> >
> >>> >a) a user would install Foreman and then install Katello as part of or
> >>> >after the installation of Foreman using either additions to the
> >>> >foreman-installer or a katello-installer that assumes the presence of
> >>> >Foreman/foreman-installer
> >>> >
> >>> >or
> >>> >
> >>> >b) a user would install Foreman+Katello using an autonomous installer
> >>>
> >>> for
> >>>
> >>> >the purpose of installing the two simultaneously?
> >>> >
> >>> >My initial assumption had been that people were expressing the route to
> >>>
> >>> be
> >>>
> >>> >(b). However, b) limits the ability to add Katello to an already
> >>>
> >>> existing
> >>>
> >>> >Foreman installation.
> >>
> >> I think (b) was the plan. Also since we'd use the same modules for
> >> Foreman
> >> part you should be able to run Foreman+Katello installer on system where
> >> Foreman was already installed by "pure" Foreman installer and in such
> >> case it
> >> should just add what's missing. It may reconfigure existing Foreman
> >> however.
> >> Maybe we could add some detection of "pure" Foreman answer file if this
> >> is a
> >> problem.
> >>
> >>
> >>
> >> Lets start with (b), and work back to (a).
>
> This is a generic question about plugins, and how they get installed.
>
> I would assume our installer should know how to install a foreman plugin.
>
> Assuming that each plugin might require additional manifest code, it should
> be possible to add more puppet classes.
>
> Do we have any existing hooks for that? e.g. when we generate the
> foreman-installer, can it be extended in a way to include other_modules.d
> from another repository ?
Currently kafo looks just to two directories for puppet modules that are
configured in installer config file. Supposing plugin would have it's own puppet
module with init.pp class it shouldn't be hard to add config option to look
elsewhere for other modules. It should be sufficient to configure in installer
config file right? Or to have hardcoded plugins directory that would be searched
automatically.
···
On Thursday 05 of December 2013 15:40:31 Ohad Levy wrote:
> On Thu, Dec 5, 2013 at 2:24 PM, Bryan Kearney wrote:
> > On 12/05/2013 02:53 AM, Marek Hulan wrote:
> >> On Wednesday 04 of December 2013 15:51:50 Eric D Helms wrote:
I think we should do option 4) (or slightly