Greg and I worked on getting the foreman-installer modules packaged via Jenkins using FPM. We can easily build deb's or RPM's from the git repo + submodules and have done it a few times now. Despite packages being publicly available in CI they never made it to the repos.
So a few things:
- We currently put the modules into /usr/share/foreman-installer - should we change this to /etc/puppet/foreman/modules?
- Should we ship the packages with 1.1?
2.5. If we are going to ship it with 1.1, should we include the answers file system that's currently in the develop branch?
-Sam
Yes, yes, yes. But then I wrote the answers generator, so I'm bound to
suggest that 
More seriously:
-
I think it makes sense to keep a clear distinction between our
stuff and the rest of the user's modules. Keeping the modules in
/usr/share makes sense for that purpose. In addition,
/etc/puppet/foreman is just as non-standard as /usr/share so we'd
still be supplying --modulepath to make use of it.
-
Definitely, assuming we can agree on (1)
2.5. The answers file and it's generator need better docs if we're
going to include it. I can look at that in the near future. Otherwise
I'm in favour - we can have sample answers files on the wiki for
various common setups, and users can supply their answers file to us
when submitting install bug reports. It's win all round.
Greg
···
On 25 January 2013 14:09, Sam Kottler wrote:
> Greg and I worked on getting the foreman-installer modules packaged via Jenkins using FPM. We can easily build deb's or RPM's from the git repo + submodules and have done it a few times now. Despite packages being publicly available in CI they never made it to the repos.
>
> So a few things:
>
> 1. We currently put the modules into /usr/share/foreman-installer - should we change this to /etc/puppet/foreman/modules?
> 2. Should we ship the packages with 1.1?
> 2.5. If we are going to ship it with 1.1, should we include the answers file system that's currently in the develop branch?
/usr/share/puppet/modules is in Puppet's default modulepath and would be
a fairly sensible place to deploy to from a package.
The only downsides are:
a) we don't put this path in our puppet module's puppet.conf, so it gets
overridden and removed
b) as mentioned on IRC earlier, the apache and concat modules in
particular might conflict with people's own… but it's a fairly simple
fix to remove our package and install elsewhere if people want to.
I'd say add the default path into our puppet.conf erb template and use that.
···
On 25/01/13 14:14, Greg Sutcliffe wrote:
> On 25 January 2013 14:09, Sam Kottler wrote:
>> Greg and I worked on getting the foreman-installer modules packaged via Jenkins using FPM. We can easily build deb's or RPM's from the git repo + submodules and have done it a few times now. Despite packages being publicly available in CI they never made it to the repos.
>>
>> So a few things:
>>
>> 1. We currently put the modules into /usr/share/foreman-installer - should we change this to /etc/puppet/foreman/modules?
>> 2. Should we ship the packages with 1.1?
>> 2.5. If we are going to ship it with 1.1, should we include the answers file system that's currently in the develop branch?
>
> Yes, yes, yes. But then I wrote the answers generator, so I'm bound to
> suggest that ;)
>
> More seriously:
>
> 1. I think it makes sense to keep a clear distinction between our
> stuff and the rest of the user's modules. Keeping the modules in
> /usr/share makes sense for that purpose. In addition,
> /etc/puppet/foreman is just as non-standard as /usr/share so we'd
> still be supplying --modulepath to make use of it.
–
Dominic Cleal
Red Hat Engineering
Even if we put the modules into /usr/share/puppet/modules we could run into issues with users who happen to have their own set of modules deployed there. Maybe /usr/share/foreman-installer actually is the best spot for the modules to prevent affecting users with existing infrastructure?
-Sam
···
----- Original Message -----
From: "Dominic Cleal"
To: foreman-dev@googlegroups.com
Sent: Friday, January 25, 2013 9:19:46 AM
Subject: Re: [foreman-dev] Including installer packages in 1.1?
On 25/01/13 14:14, Greg Sutcliffe wrote:
On 25 January 2013 14:09, Sam Kottler skottler@redhat.com wrote:
Greg and I worked on getting the foreman-installer modules packaged via Jenkins using FPM. We can easily build deb’s or RPM’s from the git repo + submodules and have done it a few times now. Despite packages being publicly available in CI they never made it to the repos.
So a few things:
- We currently put the modules into /usr/share/foreman-installer - should we change this to /etc/puppet/foreman/modules?
- Should we ship the packages with 1.1?
2.5. If we are going to ship it with 1.1, should we include the answers file system that’s currently in the develop branch?
Yes, yes, yes. But then I wrote the answers generator, so I’m bound to
suggest that 
More seriously:
- I think it makes sense to keep a clear distinction between our
stuff and the rest of the user’s modules. Keeping the modules in
/usr/share makes sense for that purpose. In addition,
/etc/puppet/foreman is just as non-standard as /usr/share so we’d
still be supplying --modulepath to make use of it.
/usr/share/puppet/modules is in Puppet’s default modulepath and would be
a fairly sensible place to deploy to from a package.
The only downsides are:
a) we don’t put this path in our puppet module’s puppet.conf, so it gets
overridden and removed
b) as mentioned on IRC earlier, the apache and concat modules in
particular might conflict with people’s own… but it’s a fairly simple
fix to remove our package and install elsewhere if people want to.
I’d say add the default path into our puppet.conf erb template and use that.
–
Dominic Cleal
Red Hat Engineering
–
