Re-using foreman-installer-modulesync

All,

Towards getting more consistency, I wanted to look at making use of the
existing foreman-installer-modulesync [1]. The options that crossed my mind
for accomplishing this:

  1. Fork, update managed_modules.yml and modulesync.yml and keep repo in sync
  2. Maintain repository with custom managed_modules.yml and modulesync.yml
    and script to clone foreman-installer-modulesync and add our .yml files to
    it locally
  3. Add Katello maintained puppet modules to the list of managed_modules for
    complete centralization

Thoughts?

Eric

[1] https://github.com/theforeman/foreman-installer-modulesync

I fully support the idea.

One technical limitation is that AFAIK modulesync can only work on one
github namespace. That rules out option 3 for now (unless you move all
katello modules to theforeman).

Maybe start with option 1 and then move on from there? Our experience
with modulesync was that it was quite a big change to implement in
itself (though surely worth it). In general we have few changes to the
modulesync repo so maintaining a fork shouldn't be much effort. When we
do have a change, it is big though. See the linked PRs on 1 and 2
(WIP) for the amount of work.

Another thing to consider is that We also use strict puppet-lint plugins
that should help make the code more future proof. That's a good thing,
but it may require some big changes to get the katello modules to pass.
A fork can allow you to start with fewer checks and then over time use
more.

Option 2 sounds like a lot of manual work that git can help you prevent.

I hope this helps.

··· On Tue, Mar 17, 2015 at 03:13:43PM -0400, Eric D Helms wrote: > All, > > Towards getting more consistency, I wanted to look at making use of the > existing foreman-installer-modulesync [1]. The options that crossed my mind > for accomplishing this: > > 1) Fork, update managed_modules.yml and modulesync.yml and keep repo in sync > 2) Maintain repository with custom managed_modules.yml and modulesync.yml > and script to clone foreman-installer-modulesync and add our .yml files to > it locally > 3) Add Katello maintained puppet modules to the list of managed_modules for > complete centralization > > Thoughts?

> > All,
> >
> > Towards getting more consistency, I wanted to look at making use of the
> > existing foreman-installer-modulesync 1. The options that crossed my
> mind
> > for accomplishing this:
> >
> > 1) Fork, update managed_modules.yml and modulesync.yml and keep repo in
> sync
> > 2) Maintain repository with custom managed_modules.yml and modulesync.yml
> > and script to clone foreman-installer-modulesync and add our .yml files
> to
> > it locally
> > 3) Add Katello maintained puppet modules to the list of managed_modules
> for
> > complete centralization
> >
> > Thoughts?
>
> I fully support the idea.
>
> One technical limitation is that AFAIK modulesync can only work on one
> github namespace. That rules out option 3 for now (unless you move all
> katello modules to theforeman).
>
> Maybe start with option 1 and then move on from there? Our experience
> with modulesync was that it was quite a big change to implement in
> itself (though surely worth it). In general we have few changes to the
> modulesync repo so maintaining a fork shouldn't be much effort. When we
> do have a change, it is big though. See the linked PRs on 1 and 2
> (WIP) for the amount of work.
>
> Another thing to consider is that We also use strict puppet-lint plugins
> that should help make the code more future proof. That's a good thing,
> but it may require some big changes to get the katello modules to pass.
> A fork can allow you to start with fewer checks and then over time use
> more.
>
> Option 2 sounds like a lot of manual work that git can help you prevent.
>
> I hope this helps.
>

It does, thanks! It occurred to me half way through reading this that we
have a variation that forking would account for as well, namely that we
have dropped 2.7 support (not that we really ever supported it not having
published modules) while you still test for it. The thing I want to prevent
the most is when update X happens to foreman-installer-modulesync it's not
weeks before we notice and update ours as well. I realize I can watch the
repository, but there are so many repositories I watch already I fear it
may get lost. :slight_smile:

Eric

··· On Tue, Mar 17, 2015 at 3:46 PM, Ewoud Kohl van Wijngaarden < ewoud@kohlvanwijngaarden.nl> wrote: > On Tue, Mar 17, 2015 at 03:13:43PM -0400, Eric D Helms wrote:


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 took an initial stab at this by forking the foreman-installer-modulesync
repository and then opening a PR against it with the necessary changes. For
anyone that has a chance to take a look:
https://github.com/Katello/foreman-installer-modulesync/pull/1

Eric

··· On Tue, Mar 17, 2015 at 4:07 PM, Eric D Helms wrote:

On Tue, Mar 17, 2015 at 3:46 PM, Ewoud Kohl van Wijngaarden < > ewoud@kohlvanwijngaarden.nl> wrote:

On Tue, Mar 17, 2015 at 03:13:43PM -0400, Eric D Helms wrote:

All,

Towards getting more consistency, I wanted to look at making use of the
existing foreman-installer-modulesync 1. The options that crossed my
mind
for accomplishing this:

  1. Fork, update managed_modules.yml and modulesync.yml and keep repo in
    sync
  2. Maintain repository with custom managed_modules.yml and
    modulesync.yml
    and script to clone foreman-installer-modulesync and add our .yml files
    to
    it locally
  3. Add Katello maintained puppet modules to the list of managed_modules
    for
    complete centralization

Thoughts?

I fully support the idea.

One technical limitation is that AFAIK modulesync can only work on one
github namespace. That rules out option 3 for now (unless you move all
katello modules to theforeman).

Maybe start with option 1 and then move on from there? Our experience
with modulesync was that it was quite a big change to implement in
itself (though surely worth it). In general we have few changes to the
modulesync repo so maintaining a fork shouldn’t be much effort. When we
do have a change, it is big though. See the linked PRs on 1 and 2
(WIP) for the amount of work.

Another thing to consider is that We also use strict puppet-lint plugins
that should help make the code more future proof. That’s a good thing,
but it may require some big changes to get the katello modules to pass.
A fork can allow you to start with fewer checks and then over time use
more.

Option 2 sounds like a lot of manual work that git can help you prevent.

I hope this helps.

It does, thanks! It occurred to me half way through reading this that we
have a variation that forking would account for as well, namely that we
have dropped 2.7 support (not that we really ever supported it not having
published modules) while you still test for it. The thing I want to prevent
the most is when update X happens to foreman-installer-modulesync it’s not
weeks before we notice and update ours as well. I realize I can watch the
repository, but there are so many repositories I watch already I fear it
may get lost. :slight_smile:

Eric


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.