There's currently an open issue, 6781, to add a capsule-service command
like we have to manage Katello services. That lead to a discussion
about packaging the capsule as an independent entity.
I think it makes sense, but looking for feedback about it.
What do we call it? 'katello-capsule' or maybe
'katello-capsule-installer'?
Do we do it for Katello 2.0? Do we basically do the same thing –
another installer indepedent of the others, or something more ambitious?
They add on to the foreman-installer. That seems appealing to me
because we're maintaining the katello-installer completely separately
from Foreman, and the new capsule-installer will need to do the same.
There's a lot of duplicated code there.
Their wizard is also nice.
If foreman-installer were the "one installer to rule them all," I think
it might make things easier.
Thoughts?
···
--
Stephen Benjamin
Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn
Handelsregister: Amtsgericht München, HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham,
Michael O’Neill, Charles Peters
Breaking our installer's out into separate repositories and separate RPMs
makes sense to me in the long run. As Greg mentions, if you look at
everything that is not the modules, the config, answers, checks and hooks
vary between installation types and would not make sense to share amongst
installers IMO. The bin/ scripts for each installer (the Katello ones at
least until foreman-installer moves more into hooks) are thin and could
potentially be singularized since all they really do is specify different
config files.
> > If foreman-installer were the "one installer to rule them all," I think
> > it might make things easier.
>
> I looked into this a while ago, but due to the time constraints for
> beta, and the work that needed doing, we chose to simply align the
> installers rather than fully merge them. I think it's a good time to
> revisit that, and I've had a brief chat with Ivan about it too.
>
> The main points will be breaking each of our modules out into it's own
> repository, so that librarian-puppet can correctly consume it -
> keeping stuff in the modules/ dir in the installer itself caused us
> pain in Foreman, and I think Katello will benefit from making the same
> move. From there, it's just a new RPM with all the modules together
> and an appropriate set of config & answers files.
>
The first aspect is already true - every module is it's own repository. The
second aspect of keeping an empty modules directory that is populated at
build time is the issue that held us back in the past as it required
re-designing the build strategy upstream and downstream for this
repository. And keeping everything in git at the versions we wanted was
just easier at the time as well. I would like to switch to the
foreman-installer strategy if/when we have the time.
Eric
···
On Wed, Jul 30, 2014 at 7:29 AM, Greg Sutcliffe wrote:
> On 30 July 2014 12:11, Stephen Benjamin wrote:
I looked into this a while ago, but due to the time constraints for
beta, and the work that needed doing, we chose to simply align the
installers rather than fully merge them. I think it's a good time to
revisit that, and I've had a brief chat with Ivan about it too.
The main points will be breaking each of our modules out into it's own
repository, so that librarian-puppet can correctly consume it -
keeping stuff in the modules/ dir in the installer itself caused us
pain in Foreman, and I think Katello will benefit from making the same
move. From there, it's just a new RPM with all the modules together
and an appropriate set of config & answers files.
In general, +1, and I'd be happy to help.
Greg
···
On 30 July 2014 12:11, Stephen Benjamin wrote:
> If foreman-installer were the "one installer to rule them all," I think
> it might make things easier.
> Breaking our installer's out into separate repositories and separate RPMs
> makes sense to me in the long run.
For foreman-installer gathering the modules through librarian-puppet is
just a build time step. It still ends up as a single RPM. I'm not sure
shipping every module as its own RPM is worth the effort.
···
On Wed, Jul 30, 2014 at 08:11:54AM -0400, Eric D Helms wrote:
As Greg mentions, if you look at everything that is not the modules,
the config, answers, checks and hooks vary between installation types
and would not make sense to share amongst installers IMO. The bin/
scripts for each installer (the Katello ones at least until
foreman-installer moves more into hooks) are thin and could
potentially be singularized since all they really do is specify
different config files.
If foreman-installer were the “one installer to rule them all,” I think
it might make things easier.
I looked into this a while ago, but due to the time constraints for
beta, and the work that needed doing, we chose to simply align the
installers rather than fully merge them. I think it’s a good time to
revisit that, and I’ve had a brief chat with Ivan about it too.
The main points will be breaking each of our modules out into it’s own
repository, so that librarian-puppet can correctly consume it -
keeping stuff in the modules/ dir in the installer itself caused us
pain in Foreman, and I think Katello will benefit from making the same
move. From there, it’s just a new RPM with all the modules together
and an appropriate set of config & answers files.
The first aspect is already true - every module is it’s own repository. The
second aspect of keeping an empty modules directory that is populated at
build time is the issue that held us back in the past as it required
re-designing the build strategy upstream and downstream for this
repository. And keeping everything in git at the versions we wanted was
just easier at the time as well. I would like to switch to the
foreman-installer strategy if/when we have the time.
> > Breaking our installer's out into separate repositories and separate RPMs
> > makes sense to me in the long run.
>
> For foreman-installer gathering the modules through librarian-puppet is
> just a build time step. It still ends up as a single RPM. I'm not sure
> shipping every module as its own RPM is worth the effort.
>
We have multiple installers - katello-installer, katello-devel-installer,
and capsule-installer that all use a different set of modules and
configurations to setup different elements is what I was referring to. As
to each module as an RPM, I have been curious over the past few months why
puppet modules aren't packaged for the native OS. All other things (e.g.
ruby gems, python packages etc.) seem to do this.
Eric
···
On Wed, Jul 30, 2014 at 8:42 AM, Ewoud Kohl van Wijngaarden < ewoud@kohlvanwijngaarden.nl> wrote:
> On Wed, Jul 30, 2014 at 08:11:54AM -0400, Eric D Helms wrote:
As Greg mentions, if you look at everything that is not the modules,
the config, answers, checks and hooks vary between installation types
and would not make sense to share amongst installers IMO. The bin/
scripts for each installer (the Katello ones at least until
foreman-installer moves more into hooks) are thin and could
potentially be singularized since all they really do is specify
different config files.
If foreman-installer were the “one installer to rule them all,” I
think
it might make things easier.
I looked into this a while ago, but due to the time constraints for
beta, and the work that needed doing, we chose to simply align the
installers rather than fully merge them. I think it’s a good time to
revisit that, and I’ve had a brief chat with Ivan about it too.
The main points will be breaking each of our modules out into it’s own
repository, so that librarian-puppet can correctly consume it -
keeping stuff in the modules/ dir in the installer itself caused us
pain in Foreman, and I think Katello will benefit from making the same
move. From there, it’s just a new RPM with all the modules together
and an appropriate set of config & answers files.
The first aspect is already true - every module is it’s own repository.
The
second aspect of keeping an empty modules directory that is populated at
build time is the issue that held us back in the past as it required
re-designing the build strategy upstream and downstream for this
repository. And keeping everything in git at the versions we wanted was
just easier at the time as well. I would like to switch to the
foreman-installer strategy if/when we have the time.
> > We have multiple installers - katello-installer, katello-devel-installer,
> > and capsule-installer that all use a different set of modules and
> > configurations to setup different elements is what I was referring to.
>
> Are they really different installers? Or are they just different
> config files supplied to the same set of modules? We already use
> basename to allow us to "create" a new installer by simply renaming
> the starting script, and it will appropriately pick up the new name's
> config and answer files. As such, it seems like that could still be a
> single RPM (or just a rebuild with a rename).
>
The hooks and checks (e.g. how you reset the data on them, the output
message when the installer completes) would also differ per installer. For
example, the way that the output message at successful completion of relies
on what modules are enabled via the answer file to grab params from as I
understand how it works in Kafo and the message may differ per installer
type.
Eric
···
On Wed, Jul 30, 2014 at 9:02 AM, Greg Sutcliffe wrote:
> On 30 July 2014 13:59, Eric D Helms wrote:
As to
each module as an RPM, I have been curious over the past few months why
puppet modules aren’t packaged for the native OS. All other things (e.g.
ruby gems, python packages etc.) seem to do this.
Only the popular ones - ruby in particular is very patchy for
packaging of gems, which is why we have to carry so many in our repo.
Python’s PIP packaer is starting to take off against yum/apt as well.
Puppet is no different, and newer, so it’s even more fledgling.
> We have multiple installers - katello-installer, katello-devel-installer,
> and capsule-installer that all use a different set of modules and
> configurations to setup different elements is what I was referring to.
Are they really different installers? Or are they just different
config files supplied to the same set of modules? We already use basename to allow us to "create" a new installer by simply renaming
the starting script, and it will appropriately pick up the new name's
config and answer files. As such, it seems like that could still be a
single RPM (or just a rebuild with a rename).
> As to
> each module as an RPM, I have been curious over the past few months why
> puppet modules aren't packaged for the native OS. All other things (e.g.
> ruby gems, python packages etc.) seem to do this.
Only the popular ones - ruby in particular is very patchy for
packaging of gems, which is why we have to carry so many in our repo.
Python's PIP packaer is starting to take off against yum/apt as well.
Puppet is no different, and newer, so it's even more fledgling.
···
On 30/07/14 13:59, Eric D Helms wrote:
> I have been curious over the past few months why puppet modules aren't
> packaged for the native OS. All other things (e.g. ruby gems, python
> packages etc.) seem to do this.
The hooks are drop-in to a directory - sounds like we could make the
location of that directory configurable?
The script output sounds like it could use a better approach too,
maybe we need pre-hooks and post-hooks?
···
On 30 July 2014 14:16, Eric D Helms wrote:
> The hooks and checks (e.g. how you reset the data on them, the output
> message when the installer completes) would also differ per installer. For
> example, the way that the output message at successful completion of relies
> on what modules are enabled via the answer file to grab params from as I
> understand how it works in Kafo and the message may differ per installer
> type.
Maybe not Fedora, but puppet-gluster is being packaged as RPM1 which
could be a good starting point.
···
On Wed, Jul 30, 2014 at 02:06:15PM +0100, Dominic Cleal wrote:
> On 30/07/14 13:59, Eric D Helms wrote:
> > I have been curious over the past few months why puppet modules aren't
> > packaged for the native OS. All other things (e.g. ruby gems, python
> > packages etc.) seem to do this.
>
> Debian has started doing this
> (https://packages.debian.org/search?keywords=puppet-module), but I'm not
> aware of equivalent Fedora Puppet packaging guidelines.
> > The hooks and checks (e.g. how you reset the data on them, the output
> > message when the installer completes) would also differ per installer.
> For
> > example, the way that the output message at successful completion of
> relies
> > on what modules are enabled via the answer file to grab params from as I
> > understand how it works in Kafo and the message may differ per installer
> > type.
>
> The hooks are drop-in to a directory - sounds like we could make the
> location of that directory configurable?
>
> The script output sounds like it could use a better approach too,
> maybe we need pre-hooks and post-hooks?
>
