Aligning Foreman & Katello git repositories

Hello all,

As many of you know we have some overlapping work between Foreman and
Katello. This is an effort to reduce some of this. This is only
focussing on git repositories but once this is in place this should be
easier. It's all proposals and we will need to work out details.

One might notice that much of this has been talked about before but
never reached a conclusion, which is something we tend to do a lot.
Let's break the cycle and make some decisions.

foreman-bats -> forklift merge

Currently we have foreman-bats1 and forklift2 which both include
a vagrant config and bats tests. I'd propose we merge foreman-bats into
forklift and deprecate foreman-bats. Most of bats (if not all) should
already be there so I believe we just need to verify we can test Foreman
using Forklift. Since I added Debian we need to make Ubuntu work and
verify Jenkins can still test everything it used to.

This should be a relative easy task for which a lot of work has already
been done.

Tasks/Challenges I can think of:

  • Add Ubuntu to Forklift
  • Get bats passing on all supported configs
  • Verify foreman-bats is no longer used on CI
  • Add a deprecation warning in foreman-bats' README

katello-packaging -> foreman-packaging

At the moment Foreman packages are maintained in foreman-packaging3
with an RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop)
and a the same with deb/ for obvious reasons. On the Katello side there
is katello-packaging4 with KATELLO-3.3, KATELLO-3.4 and master.

There was a discussion in #15415 about merging katello-packaging into
foreman-packaging, but it didn't reach a conclusion. The general
opinions were in favour but there might be space and traffic constraints
when actually building the packages.

My proposal is to revive this effort. Given the practical constraints
are related to the hosting it makes sense to me to start with just
merging the git repositories. Is it possible to do the builds from a
single git repository and end up on different servers for now?

If that's possible, we can look at finding proper hosting and which yum
repositories we should offer.

katello modules -> theforeman namespace (including modulesync)

Right now we have a foreman-installer-modulesync6 and
katello-installer-modulesync7 to maintain the base layout of modules.
These are all very similar and with little effort we can maintain all
modules with the same layout.

The bigger impact is that we need to migrate all modules at least on the
github level to the theforeman github namespace. It also implies that
when you make changes to modulesync that needs to be applied to about
double the modules which can be more effort. The upside is that the
overall quality will be higher.

If this all works well we can look at moving the katello modules to the
foreman namespace on the Puppet forge as well but I think that benefit
is smaller and will take effort on the (direct) users since the forge
doesn't support redirects.

katello-installer -> foreman-installer

Currently the katello-installer8 builds on the foreman-installer9
with additional modules and scenarios. Sometimes the katello build
breaks on dependencies and then the cache gets out of sync with the
foreman thus breaking on older builds as well.

I'd like to merge this in a single installer with one set of modules and
multiple scenarios. The impact is that the installer will be bigger but
the katello-installer should be less fragile. It can also simplify
packaging.

Care will need to be taken that the needed repositories are present but
there are multiple ways of fixing this. Currently we assume the user has
installed the katello release RPM which enables the needed yum
repositories but that will not be true anymore if we ship it within
foreman-installer.

We'll also want to remove/disable the katello scenarios on
Debian/Ubuntu.

You may notice I haven't thought this through too much and it may depend
on a unified Yum repository structure but there are big usability and
reliability wins we can gain.

Sounds very good to me. Let's do this and find solutions for problems as we go.
If bandwidth is an issue, Cloudflare CDN might be worth checking out for the packages.

Timo

··· > On 2. Aug 2017, at 14:33, Ewoud Kohl van Wijngaarden wrote: > > Hello all, > > As many of you know we have some overlapping work between Foreman and Katello. This is an effort to reduce some of this. This is only focussing on git repositories but once this is in place this should be easier. It's all proposals and we will need to work out details. > > One might notice that much of this has been talked about before but never reached a conclusion, which is something we tend to do a lot. Let's break the cycle and make some decisions. > > # foreman-bats -> forklift merge > > Currently we have foreman-bats[1] and forklift[2] which both include a vagrant config and bats tests. I'd propose we merge foreman-bats into forklift and deprecate foreman-bats. Most of bats (if not all) should already be there so I believe we just need to verify we can test Foreman using Forklift. Since I added Debian we need to make Ubuntu work and verify Jenkins can still test everything it used to. > > This should be a relative easy task for which a lot of work has already been done. > > Tasks/Challenges I can think of: > > * Add Ubuntu to Forklift > * Get bats passing on all supported configs > * Verify foreman-bats is no longer used on CI > * Add a deprecation warning in foreman-bats' README > > # katello-packaging -> foreman-packaging > > At the moment Foreman packages are maintained in foreman-packaging[3] with an RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop) and a the same with deb/ for obvious reasons. On the Katello side there is katello-packaging[4] with KATELLO-3.3, KATELLO-3.4 and master. > > There was a discussion in #1541[5] about merging katello-packaging into foreman-packaging, but it didn't reach a conclusion. The general opinions were in favour but there might be space and traffic constraints when actually building the packages. > > My proposal is to revive this effort. Given the practical constraints are related to the hosting it makes sense to me to start with just merging the git repositories. Is it possible to do the builds from a single git repository and end up on different servers for now? > > If that's possible, we can look at finding proper hosting and which yum repositories we should offer. > > # katello modules -> theforeman namespace (including modulesync) > > Right now we have a foreman-installer-modulesync[6] and katello-installer-modulesync[7] to maintain the base layout of modules. These are all very similar and with little effort we can maintain all modules with the same layout. > > The bigger impact is that we need to migrate all modules at least on the github level to the theforeman github namespace. It also implies that when you make changes to modulesync that needs to be applied to about double the modules which can be more effort. The upside is that the overall quality will be higher. > > If this all works well we can look at moving the katello modules to the foreman namespace on the Puppet forge as well but I think that benefit is smaller and will take effort on the (direct) users since the forge doesn't support redirects. > > # katello-installer -> foreman-installer > > Currently the katello-installer[8] builds on the foreman-installer[9] with additional modules and scenarios. Sometimes the katello build breaks on dependencies and then the cache gets out of sync with the foreman thus breaking on older builds as well. > > I'd like to merge this in a single installer with one set of modules and multiple scenarios. The impact is that the installer will be bigger but the katello-installer should be less fragile. It can also simplify packaging. > > Care will need to be taken that the needed repositories are present but there are multiple ways of fixing this. Currently we assume the user has installed the katello release RPM which enables the needed yum repositories but that will not be true anymore if we ship it within foreman-installer. > > We'll also want to remove/disable the katello scenarios on Debian/Ubuntu. > > You may notice I haven't thought this through too much and it may depend on a unified Yum repository structure but there are big usability and reliability wins we can gain. > > [1]: https://github.com/theforeman/foreman-bats > [2]: https://github.com/theforeman/forklift > [3]: https://github.com/theforeman/foreman-packaging > [4]: https://github.com/katello/katello-packaging > [5]: https://github.com/theforeman/foreman-packaging/pull/1541 > [6]: https://github.com/theforeman/foreman-installer-modulesync > [7]: https://github.com/katello/foreman-installer-modulesync > [8]: https://github.com/katello/katello-installer > [9]: https://github.com/theforeman/foreman-installer > > -- > 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/d/optout.

> Hello all,
>
> As many of you know we have some overlapping work between Foreman and
> Katello. This is an effort to reduce some of this. This is only focussing
> on git repositories but once this is in place this should be easier. It's
> all proposals and we will need to work out details.
>
> One might notice that much of this has been talked about before but never
> reached a conclusion, which is something we tend to do a lot. Let's break
> the cycle and make some decisions.
>
> # foreman-bats -> forklift merge
>
> Currently we have foreman-bats1 and forklift2 which both include a
> vagrant config and bats tests. I'd propose we merge foreman-bats into
> forklift and deprecate foreman-bats. Most of bats (if not all) should
> already be there so I believe we just need to verify we can test Foreman
> using Forklift. Since I added Debian we need to make Ubuntu work and verify
> Jenkins can still test everything it used to.
>
> This should be a relative easy task for which a lot of work has already
> been done.
>
> Tasks/Challenges I can think of:
>
> * Add Ubuntu to Forklift
> * Get bats passing on all supported configs
> * Verify foreman-bats is no longer used on CI
> * Add a deprecation warning in foreman-bats' README
>

I think this would be great to centralize. What are your thoughts on
whether we are over loading Forklift as is? Should we consider merging all
bats to a single repository and keeping the testing aspect a separate
entity from the deployment entity?

>
> # katello-packaging -> foreman-packaging
>
> At the moment Foreman packages are maintained in foreman-packaging3 with
> an RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop) and a the
> same with deb/ for obvious reasons. On the Katello side there is
> katello-packaging4 with KATELLO-3.3, KATELLO-3.4 and master.
>
> There was a discussion in #15415 about merging katello-packaging into
> foreman-packaging, but it didn't reach a conclusion. The general opinions
> were in favour but there might be space and traffic constraints when
> actually building the packages.
>
> My proposal is to revive this effort. Given the practical constraints are
> related to the hosting it makes sense to me to start with just merging the
> git repositories. Is it possible to do the builds from a single git
> repository and end up on different servers for now?
>
> If that's possible, we can look at finding proper hosting and which yum
> repositories we should offer.
>

I would definitely like to see this, and just because the git repositories
merge doe snot mean we have to modify our yum repository and Koji/Copr
management immediately. One issue that stands unresolved is how to allow
for independent updates to Katello or really any plugin within the yum
repositories. This is something I am still giving a lot of thought to,
plugin release streams so that broken plugins aren't automatically pushed
out to the yum repositories. This would also open up nightly builds for
plugins (of which katello has a requirement on already).

>
> # katello modules -> theforeman namespace (including modulesync)
>
> Right now we have a foreman-installer-modulesync6 and
> katello-installer-modulesync7 to maintain the base layout of modules.
> These are all very similar and with little effort we can maintain all
> modules with the same layout.
>
> The bigger impact is that we need to migrate all modules at least on the
> github level to the theforeman github namespace. It also implies that when
> you make changes to modulesync that needs to be applied to about double the
> modules which can be more effort. The upside is that the overall quality
> will be higher.
>
> If this all works well we can look at moving the katello modules to the
> foreman namespace on the Puppet forge as well but I think that benefit is
> smaller and will take effort on the (direct) users since the forge doesn't
> support redirects.
>

Yes please!

>
> # katello-installer -> foreman-installer
>
> Currently the katello-installer8 builds on the foreman-installer9 with
> additional modules and scenarios. Sometimes the katello build breaks on
> dependencies and then the cache gets out of sync with the foreman thus
> breaking on older builds as well.
>
> I'd like to merge this in a single installer with one set of modules and
> multiple scenarios. The impact is that the installer will be bigger but the
> katello-installer should be less fragile. It can also simplify packaging.
>
> Care will need to be taken that the needed repositories are present but
> there are multiple ways of fixing this. Currently we assume the user has
> installed the katello release RPM which enables the needed yum repositories
> but that will not be true anymore if we ship it within foreman-installer.
>
> We'll also want to remove/disable the katello scenarios on Debian/Ubuntu.
>

Yes please! The benefits here do out weight the issues that need addressing.

··· On Wed, Aug 2, 2017 at 8:33 AM, Ewoud Kohl van Wijngaarden < ewoud@kohlvanwijngaarden.nl> wrote:

You may notice I haven’t thought this through too much and it may depend
on a unified Yum repository structure but there are big usability and
reliability wins we can gain.


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/d/optout.


Eric D. Helms
Red Hat Engineering

+1 for every suggestion! Which would you like to start with? I'd be interested
in helping with forklift being used in jenkins for running bats tests. Later I
hope with installers merge.

··· -- Marek

On středa 2. srpna 2017 14:33:44 CEST Ewoud Kohl van Wijngaarden wrote:

Hello all,

As many of you know we have some overlapping work between Foreman and
Katello. This is an effort to reduce some of this. This is only
focussing on git repositories but once this is in place this should be
easier. It’s all proposals and we will need to work out details.

One might notice that much of this has been talked about before but
never reached a conclusion, which is something we tend to do a lot.
Let’s break the cycle and make some decisions.

foreman-bats -> forklift merge

Currently we have foreman-bats1 and forklift2 which both include
a vagrant config and bats tests. I’d propose we merge foreman-bats into
forklift and deprecate foreman-bats. Most of bats (if not all) should
already be there so I believe we just need to verify we can test Foreman
using Forklift. Since I added Debian we need to make Ubuntu work and
verify Jenkins can still test everything it used to.

This should be a relative easy task for which a lot of work has already
been done.

Tasks/Challenges I can think of:

  • Add Ubuntu to Forklift
  • Get bats passing on all supported configs
  • Verify foreman-bats is no longer used on CI
  • Add a deprecation warning in foreman-bats’ README

katello-packaging -> foreman-packaging

At the moment Foreman packages are maintained in foreman-packaging3
with an RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop)
and a the same with deb/ for obvious reasons. On the Katello side there
is katello-packaging4 with KATELLO-3.3, KATELLO-3.4 and master.

There was a discussion in #15415 about merging katello-packaging into
foreman-packaging, but it didn’t reach a conclusion. The general
opinions were in favour but there might be space and traffic constraints
when actually building the packages.

My proposal is to revive this effort. Given the practical constraints
are related to the hosting it makes sense to me to start with just
merging the git repositories. Is it possible to do the builds from a
single git repository and end up on different servers for now?

If that’s possible, we can look at finding proper hosting and which yum
repositories we should offer.

katello modules -> theforeman namespace (including modulesync)

Right now we have a foreman-installer-modulesync6 and
katello-installer-modulesync7 to maintain the base layout of modules.
These are all very similar and with little effort we can maintain all
modules with the same layout.

The bigger impact is that we need to migrate all modules at least on the
github level to the theforeman github namespace. It also implies that
when you make changes to modulesync that needs to be applied to about
double the modules which can be more effort. The upside is that the
overall quality will be higher.

If this all works well we can look at moving the katello modules to the
foreman namespace on the Puppet forge as well but I think that benefit
is smaller and will take effort on the (direct) users since the forge
doesn’t support redirects.

katello-installer -> foreman-installer

Currently the katello-installer8 builds on the foreman-installer9
with additional modules and scenarios. Sometimes the katello build
breaks on dependencies and then the cache gets out of sync with the
foreman thus breaking on older builds as well.

I’d like to merge this in a single installer with one set of modules and
multiple scenarios. The impact is that the installer will be bigger but
the katello-installer should be less fragile. It can also simplify
packaging.

Care will need to be taken that the needed repositories are present but
there are multiple ways of fixing this. Currently we assume the user has
installed the katello release RPM which enables the needed yum
repositories but that will not be true anymore if we ship it within
foreman-installer.

We’ll also want to remove/disable the katello scenarios on
Debian/Ubuntu.

You may notice I haven’t thought this through too much and it may depend
on a unified Yum repository structure but there are big usability and
reliability wins we can gain.

Overall, big +1 from me - it'll make my life easier too. Whilst I
appreciate Katello is a big project in it's own right, it's never felt
good to me that it lives in it's own world despite every other plugin
being in the Foreman namespace. Obviously there's historical reasons
for that, but tradition for tradtion's sake is no argument at all :slight_smile:

Some thoughts on the various points:

foreman-bats -> forklift merge

This does indeed feel like duplication of effort. It's also an area
where we have some flexibility, since we can choose to disable some
types of test in the short term if we need to (obviously thats not
ideal though). The path forward is clearly to get forklift where it
needs to be before removing bats for good, +1 there.

There's also the CentOS CI project, but I'll send a separate mail about
that since it's additional to bats/forklift rather than integral.

katello-packaging -> foreman-packaging

Overall, in favour, it makes it possible for me to do better metrics on
Katello usage.

About 1/3rd of our substantial budget from Rackspace goes on bandwidth,
but what I can't see is how much of that is our own consumption for
package building and testing. It may be worth looking into caching /
internal Rackspace-IP mirrors for our builders before we take the
plunge on this.

As for the modules / installer, +1 in general, no specific comments :slight_smile:

If I can help at all from an infra perspective, let me know, especially
if you need insights into the Rackspace usage etc.

Greg

>
>> Hello all,
>>
>> As many of you know we have some overlapping work between Foreman and
>> Katello. This is an effort to reduce some of this. This is only focussing
>> on git repositories but once this is in place this should be easier. It's
>> all proposals and we will need to work out details.
>>
>> One might notice that much of this has been talked about before but never
>> reached a conclusion, which is something we tend to do a lot. Let's break
>> the cycle and make some decisions.
>>
>> # foreman-bats -> forklift merge
>>
>> Currently we have foreman-bats1 and forklift2 which both include a
>> vagrant config and bats tests. I'd propose we merge foreman-bats into
>> forklift and deprecate foreman-bats. Most of bats (if not all) should
>> already be there so I believe we just need to verify we can test Foreman
>> using Forklift. Since I added Debian we need to make Ubuntu work and verify
>> Jenkins can still test everything it used to.
>>
>> This should be a relative easy task for which a lot of work has already
>> been done.
>>
>> Tasks/Challenges I can think of:
>>
>> * Add Ubuntu to Forklift
>> * Get bats passing on all supported configs
>> * Verify foreman-bats is no longer used on CI
>> * Add a deprecation warning in foreman-bats' README
>>
>
>I think this would be great to centralize. What are your thoughts on
>whether we are over loading Forklift as is? Should we consider merging all
>bats to a single repository and keeping the testing aspect a separate
>entity from the deployment entity?

While I think we cover a lot of things in forklift I do think it's an
advantage right now and splitting of bats doesn't add a lot. There is
tight coupling between the provisioning of the server(s) and testing
them so often you will modify both.

>
>>
>> # katello-packaging -> foreman-packaging
>>
>> At the moment Foreman packages are maintained in foreman-packaging3 with
>> an RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop) and a the
>> same with deb/ for obvious reasons. On the Katello side there is
>> katello-packaging4 with KATELLO-3.3, KATELLO-3.4 and master.
>>
>> There was a discussion in #15415 about merging katello-packaging into
>> foreman-packaging, but it didn't reach a conclusion. The general opinions
>> were in favour but there might be space and traffic constraints when
>> actually building the packages.
>>
>> My proposal is to revive this effort. Given the practical constraints are
>> related to the hosting it makes sense to me to start with just merging the
>> git repositories. Is it possible to do the builds from a single git
>> repository and end up on different servers for now?
>>
>> If that's possible, we can look at finding proper hosting and which yum
>> repositories we should offer.
>>
>
>I would definitely like to see this, and just because the git repositories
>merge doe snot mean we have to modify our yum repository and Koji/Copr
>management immediately.

It's good to hear that merging git repos is a separate action. That
means we can proceed step by step.

>One issue that stands unresolved is how to allow for independent
>updates to Katello or really any plugin within the yum repositories.
>This is something I am still giving a lot of thought to, plugin release
>streams so that broken plugins aren't automatically pushed out to the
>yum repositories. This would also open up nightly builds for plugins
>(of which katello has a requirement on already).

I'm not sure what you mean by this. Don't we do this already?

··· On Thu, Aug 03, 2017 at 01:16:05PM -0400, Eric D Helms wrote: >On Wed, Aug 2, 2017 at 8:33 AM, Ewoud Kohl van Wijngaarden < >ewoud@kohlvanwijngaarden.nl> wrote:

katello modules -> theforeman namespace (including modulesync)

Right now we have a foreman-installer-modulesync6 and
katello-installer-modulesync7 to maintain the base layout of modules.
These are all very similar and with little effort we can maintain all
modules with the same layout.

The bigger impact is that we need to migrate all modules at least on the
github level to the theforeman github namespace. It also implies that when
you make changes to modulesync that needs to be applied to about double the
modules which can be more effort. The upside is that the overall quality
will be higher.

If this all works well we can look at moving the katello modules to the
foreman namespace on the Puppet forge as well but I think that benefit is
smaller and will take effort on the (direct) users since the forge doesn’t
support redirects.

Yes please!

katello-installer -> foreman-installer

Currently the katello-installer8 builds on the foreman-installer9 with
additional modules and scenarios. Sometimes the katello build breaks on
dependencies and then the cache gets out of sync with the foreman thus
breaking on older builds as well.

I’d like to merge this in a single installer with one set of modules and
multiple scenarios. The impact is that the installer will be bigger but the
katello-installer should be less fragile. It can also simplify packaging.

Care will need to be taken that the needed repositories are present but
there are multiple ways of fixing this. Currently we assume the user has
installed the katello release RPM which enables the needed yum repositories
but that will not be true anymore if we ship it within foreman-installer.

We’ll also want to remove/disable the katello scenarios on Debian/Ubuntu.

Yes please! The benefits here do out weight the issues that need addressing.

You may notice I haven’t thought this through too much and it may depend
on a unified Yum repository structure but there are big usability and
reliability wins we can gain.


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/d/optout.


Eric D. Helms
Red Hat Engineering


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/d/optout.

I'd start to with using forklift for bats testing because it's the
easiest and most stand alone action.

··· On Fri, Aug 04, 2017 at 02:13:16PM +0200, Marek Hulán wrote: >+1 for every suggestion! Which would you like to start with? I'd be interested >in helping with forklift being used in jenkins for running bats tests. Later I >hope with installers merge. > >-- >Marek > >On středa 2. srpna 2017 14:33:44 CEST Ewoud Kohl van Wijngaarden wrote: >> Hello all, >> >> As many of you know we have some overlapping work between Foreman and >> Katello. This is an effort to reduce some of this. This is only >> focussing on git repositories but once this is in place this should be >> easier. It's all proposals and we will need to work out details. >> >> One might notice that much of this has been talked about before but >> never reached a conclusion, which is something we tend to do a lot. >> Let's break the cycle and make some decisions. >> >> # foreman-bats -> forklift merge >> >> Currently we have foreman-bats[1] and forklift[2] which both include >> a vagrant config and bats tests. I'd propose we merge foreman-bats into >> forklift and deprecate foreman-bats. Most of bats (if not all) should >> already be there so I believe we just need to verify we can test Foreman >> using Forklift. Since I added Debian we need to make Ubuntu work and >> verify Jenkins can still test everything it used to. >> >> This should be a relative easy task for which a lot of work has already >> been done. >> >> Tasks/Challenges I can think of: >> >> * Add Ubuntu to Forklift >> * Get bats passing on all supported configs >> * Verify foreman-bats is no longer used on CI >> * Add a deprecation warning in foreman-bats' README >> >> # katello-packaging -> foreman-packaging >> >> At the moment Foreman packages are maintained in foreman-packaging[3] >> with an RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop) >> and a the same with deb/ for obvious reasons. On the Katello side there >> is katello-packaging[4] with KATELLO-3.3, KATELLO-3.4 and master. >> >> There was a discussion in #1541[5] about merging katello-packaging into >> foreman-packaging, but it didn't reach a conclusion. The general >> opinions were in favour but there might be space and traffic constraints >> when actually building the packages. >> >> My proposal is to revive this effort. Given the practical constraints >> are related to the hosting it makes sense to me to start with just >> merging the git repositories. Is it possible to do the builds from a >> single git repository and end up on different servers for now? >> >> If that's possible, we can look at finding proper hosting and which yum >> repositories we should offer. >> >> # katello modules -> theforeman namespace (including modulesync) >> >> Right now we have a foreman-installer-modulesync[6] and >> katello-installer-modulesync[7] to maintain the base layout of modules. >> These are all very similar and with little effort we can maintain all >> modules with the same layout. >> >> The bigger impact is that we need to migrate all modules at least on the >> github level to the theforeman github namespace. It also implies that >> when you make changes to modulesync that needs to be applied to about >> double the modules which can be more effort. The upside is that the >> overall quality will be higher. >> >> If this all works well we can look at moving the katello modules to the >> foreman namespace on the Puppet forge as well but I think that benefit >> is smaller and will take effort on the (direct) users since the forge >> doesn't support redirects. >> >> # katello-installer -> foreman-installer >> >> Currently the katello-installer[8] builds on the foreman-installer[9] >> with additional modules and scenarios. Sometimes the katello build >> breaks on dependencies and then the cache gets out of sync with the >> foreman thus breaking on older builds as well. >> >> I'd like to merge this in a single installer with one set of modules and >> multiple scenarios. The impact is that the installer will be bigger but >> the katello-installer should be less fragile. It can also simplify >> packaging. >> >> Care will need to be taken that the needed repositories are present but >> there are multiple ways of fixing this. Currently we assume the user has >> installed the katello release RPM which enables the needed yum >> repositories but that will not be true anymore if we ship it within >> foreman-installer. >> >> We'll also want to remove/disable the katello scenarios on >> Debian/Ubuntu. >> >> You may notice I haven't thought this through too much and it may depend >> on a unified Yum repository structure but there are big usability and >> reliability wins we can gain. >> >> [1]: https://github.com/theforeman/foreman-bats >> [2]: https://github.com/theforeman/forklift >> [3]: https://github.com/theforeman/foreman-packaging >> [4]: https://github.com/katello/katello-packaging >> [5]: https://github.com/theforeman/foreman-packaging/pull/1541 >> [6]: https://github.com/theforeman/foreman-installer-modulesync >> [7]: https://github.com/katello/foreman-installer-modulesync >> [8]: https://github.com/katello/katello-installer >> [9]: https://github.com/theforeman/foreman-installer > > >-- >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/d/optout.