Hey foreman-dev,
Greg, myself and many of the installer users think it's become clear
over the past few months that it's necessary to start releasing the
Foreman installer modules in tandem with Foreman versions. For example,
1.0.1 would be a known-working configuration that we've tested
extensively. The primary motivation for this change is to encourage
stability for point releases while still making rapid improvements to
the installation process.
Here are a few different questions:
- Do people want to see our modules on the Forge? Are they too
Foreman-specific to be useful for others beyond being examples?
- Should we unify all the submodules into a single repo? Start using
librarian-puppet (I think this adds lots of complexity for newcomers)?
- If we put all the modules directly into the repo should we continue
maintaining the individual repos with cherry picks from the central repo?
Hopefully this will start a conversation about improving the installer
modules so they are easier to get started with and more useful overall.
-S
> 1) Do people want to see our modules on the Forge? Are they too
> Foreman-specific to be useful for others beyond being examples?
Regardless of specificity, it would be great to have your modules
hosted on the forge.
> 2) Should we unify all the submodules into a single repo? Start using
> librarian-puppet (I think this adds lots of complexity for newcomers)?
librarian-puppet seems to be the direction most people are taking for
their site modules versus submodules. If the modules are forge hosted,
dependencies can be followed etc.
ken.
I agree that librarian is a good tool for managing modules from
different sources, but I'm not sure it is a good fit for our user base.
People without any puppet experience often want to try out the Foreman;
librarian might be an additional barrier to entry.
I think it should still be considered because it's a nice tool, but the
real discussion in my mind at this point is about whether we want to put
all the modules into the foreman-installer repo or not.
···
On 10/03/2012 03:04 AM, Ken Barber wrote:
>> 1) Do people want to see our modules on the Forge? Are they too
>> Foreman-specific to be useful for others beyond being examples?
>
> Regardless of specificity, it would be great to have your modules
> hosted on the forge.
>
>> 2) Should we unify all the submodules into a single repo? Start using
>> librarian-puppet (I think this adds lots of complexity for newcomers)?
>
> librarian-puppet seems to be the direction most people are taking for
> their site modules versus submodules. If the modules are forge hosted,
> dependencies can be followed etc.
>
> ken.
>
-1 in moving submodules into one repo, +1 for tagging foreman-installer
repo itself.
Ohad
···
On Thu, Oct 4, 2012 at 2:39 AM, Sam Kottler wrote:
On 10/03/2012 03:04 AM, Ken Barber wrote:
- Do people want to see our modules on the Forge? Are they too
Foreman-specific to be useful for others beyond being examples?
Regardless of specificity, it would be great to have your modules
hosted on the forge.
- Should we unify all the submodules into a single repo? Start using
librarian-puppet (I think this adds lots of complexity for newcomers)?
librarian-puppet seems to be the direction most people are taking for
their site modules versus submodules. If the modules are forge hosted,
dependencies can be followed etc.
ken.
I agree that librarian is a good tool for managing modules from
different sources, but I’m not sure it is a good fit for our user base.
People without any puppet experience often want to try out the Foreman;
librarian might be an additional barrier to entry.
I think it should still be considered because it’s a nice tool, but the
real discussion in my mind at this point is about whether we want to put
all the modules into the foreman-installer repo or not.
We regularly have to deal with merge order issues on pull requests in different repos; putting the modules into one repo would eliminate those problems.
···
----- Original Message -----
From: "Ohad Levy"
To: foreman-dev@googlegroups.com
Sent: Thursday, October 4, 2012 9:42:51 AM
Subject: Re: [foreman-dev] Formal releases of foreman-installer
On Thu, Oct 4, 2012 at 2:39 AM, Sam Kottler < skottler@redhat.com > wrote:
On 10/03/2012 03:04 AM, Ken Barber wrote:
- Do people want to see our modules on the Forge? Are they too
Foreman-specific to be useful for others beyond being examples?
Regardless of specificity, it would be great to have your modules
hosted on the forge.
- Should we unify all the submodules into a single repo? Start using
librarian-puppet (I think this adds lots of complexity for newcomers)?
librarian-puppet seems to be the direction most people are taking for
their site modules versus submodules. If the modules are forge hosted,
dependencies can be followed etc.
ken.
I agree that librarian is a good tool for managing modules from different sources, but I’m not sure it is a good fit for our user base. People without any puppet experience often want to try out the Foreman; librarian might be an additional barrier to entry.
I think it should still be considered because it’s a nice tool, but the real discussion in my mind at this point is about whether we want to put all the modules into the foreman-installer repo or not.
-1 in moving submodules into one repo, +1 for tagging foreman-installer repo itself.
Ohad
I see us supporting two main use cases. Unfortunately they conflict a bit.
Use case #1 is when a user wants to install Foreman for the first
time. They likely have no puppet infrastructure yet, and want to
bootstrap the system as quickly as possibly. In my opinion, that means
they're aren't interested in the Forge, or librarian-puppet, or
anything other than the shortest number of commands to get a working
system. Submodules are not relevant either way - the user doesn't
Use case #2 is the user with an existing infrastructure, who wants to
cherry-pick some of our modules into their own tree. These people will
want to use submodules, or the forge (possibly assisted by librarian)
and to support the forge we'll need to keep the submodules anyway,
since each module needs a git repo. The downside here is that these
people are no longer referencing foreman-installer, but going straight
to the module(s) they want. If we only tag releases on
foreman-installer, they won't see them, and will end up potentially
tracking HEAD instead
The tagging of releases is a really good idea. I suggest that we tag
all the modules at a given point in time - i.e tag the installer with
a release that matches the foreman release (e.g foreman-installer
v1.0.1) and then tag each of the referenced SHAsums in the submodules.
It's only 10mins extra work, and means we've got an exact record of
what was released. It also helps out the people in Case 2.
Once we've tagged at least one release, we can also create a "develop"
branch, just like foreman and foreman-proxy. This can be used to test
updates to the installer without causing as much of a problem to other
users. That will help ease (but not remove) the merge-order issues we
get, since we can fix up develop as and when we find problems.
Or…
there's a completely different and orthogonal-to-the-above idea. We
could start using subtree merge instead of submodules. I've done this
in the past, and it's a bit brain-twisting to get used to, but has the
effect of presenting foreman-installer as a single repo (thus removing
merge-order issues, as single PRs can be submitted there) but also
allows the correct content to go to the subtree repos. I can knock up
a demo if anyone wants to see how this works.
With subtree, we could get the best of everything - but it might take
a little getting used to 
Greg
That could be a pita for $osfamily = RedHat until git 1.7.11 hits EPEL.
-Josh
···
On 10/05/2012 03:24 AM, Greg Sutcliffe wrote:
> there's a completely different and orthogonal-to-the-above idea. We
> could start using subtree merge instead of submodules. I've done this
> in the past, and it's a bit brain-twisting to get used to, but has the
> effect of presenting foreman-installer as a single repo (thus removing
> merge-order issues, as single PRs can be submitted there) but also
> allows the correct content to go to the subtree repos. I can knock up
> a demo if anyone wants to see how this works.
>
> With subtree, we could get the best of everything - but it might take
> a little getting used to ;)
–
Bear in mind only committers need to care about the subtree merge - to
end users it looks like a single repo. People wanting to pull a single
module into their own trees would use the appropriate module.
···
On 12 October 2012 21:42, Joshua hoblitt wrote:
> On 10/05/2012 03:24 AM, Greg Sutcliffe wrote:
>> there's a completely different and orthogonal-to-the-above idea. We
>> could start using subtree merge instead of submodules. I've done this
>> in the past, and it's a bit brain-twisting to get used to, but has the
>> effect of presenting foreman-installer as a single repo (thus removing
>> merge-order issues, as single PRs can be submitted there) but also
>> allows the correct content to go to the subtree repos. I can knock up
>> a demo if anyone wants to see how this works.
>>
>> With subtree, we could get the best of everything - but it might take
>> a little getting used to ;)
>
> That could be a pita for $osfamily = RedHat until git 1.7.11 hits EPEL.
