(Mainly aimed at vStone and ohadlevy, but feel free to chip in :P)
Just about to start forking and updating the puppet-* modules to
support Archlinux. Most of the changes are easy enough, however,
Foreman isn't packaged for Archlinux.
Now, I could sort out a Foreman package first, but it occurred to me
that it would be nice if the module supported the git install,
probably as an optional parameter. That got me to thinking about how
we'd actually do it, since you have to get things in there like
bundler and so on.
My plan is to break down foreman/manifests/install/repos.pp into
repos/redhat.pp, repos/debian.pp and so on. Then create a
repos/git.pp, taking parameters like a Packages array, so that each
OS-specific module can do something like:
if $git-install {
$packages = ["git-core","bundler"]
include repos::git
} else {
… os-specific package instructions
}
Only problem I can see is a possible conflict over the git package,
which is also defined in puppet-git - if the user wants to Git with
Puppet, we're going to get a conflict. I'm sure I can work around that
though.
Thoughts? Sensible approach?
Greg
This could be done with a Capistrano script fairly easily.
Corey Osman
corey@logicminds.biz
Green IT and Datacenter Automation Specialist
···
On Mar 4, 2012, at 2:59 AM, Greg Sutcliffe wrote:
(Mainly aimed at vStone and ohadlevy, but feel free to chip in :P)
Just about to start forking and updating the puppet-* modules to
support Archlinux. Most of the changes are easy enough, however,
Foreman isn’t packaged for Archlinux.
Now, I could sort out a Foreman package first, but it occurred to me
that it would be nice if the module supported the git install,
probably as an optional parameter. That got me to thinking about how
we’d actually do it, since you have to get things in there like
bundler and so on.
My plan is to break down foreman/manifests/install/repos.pp into
repos/redhat.pp, repos/debian.pp and so on. Then create a
repos/git.pp, taking parameters like a Packages array, so that each
OS-specific module can do something like:
if $git-install {
$packages = [“git-core”,“bundler”]
include repos::git
} else {
… os-specific package instructions
}
Only problem I can see is a possible conflict over the git package,
which is also defined in puppet-git - if the user wants to Git with
Puppet, we’re going to get a conflict. I’m sure I can work around that
though.
Thoughts? Sensible approach?
Greg
Git install makes sense, and in the original module (if you look
though the history) we had install via tar as well.
Why not simply use the git module to install git? 
as far as it goes for bundler, you could do the same logic, e.g. if
its a know os with bundler, use it, other wise, use the gem provider.
+1
Ohad
···
On Sun, Mar 4, 2012 at 12:59 PM, Greg Sutcliffe wrote:
> (Mainly aimed at vStone and ohadlevy, but feel free to chip in :P)
>
> Just about to start forking and updating the puppet-* modules to
> support Archlinux. Most of the changes are easy enough, however,
> Foreman isn't packaged for Archlinux.
>
> Now, I could sort out a Foreman package *first*, but it occurred to me
> that it would be nice if the module supported the git install,
> probably as an optional parameter. That got me to thinking about how
> we'd actually do it, since you have to get things in there like
> bundler and so on.
>
> My plan is to break down foreman/manifests/install/repos.pp into
> repos/redhat.pp, repos/debian.pp and so on. Then create a
> repos/git.pp, taking parameters like a Packages array, so that each
> OS-specific module can do something like:
>
> if $git-install {
> $packages = ["git-core","bundler"]
> include repos::git
> } else {
> ... os-specific package instructions
> }
>
> Only problem I can see is a possible conflict over the git package,
> which is also defined in puppet-git - if the user wants to Git with
> Puppet, we're going to get a conflict. I'm sure I can work around that
> though.
>
> Thoughts? Sensible approach?
>
> Greg
> On Sun, Mar 4, 2012 at 12:59 PM, Greg Sutcliffe
>
> Git install makes sense, and in the original module (if you look
> though the history) we had install via tar as well.
> Why not simply use the git module to install git?
Yeah, that'll work. I blame not having any coffee when I wrote the OP 
> as far as it goes for bundler, you could do the same logic, e.g. if
> its a know os with bundler, use it, other wise, use the gem provider.
Might just start with gems for simplicity - I can use an Exec to run
bundle install
as the correct user, which might cut down a lot of our gem issues.
···
On 4 March 2012 12:14, Ohad Levy wrote:
true, but, afair, that wont play nicely with passenger, as it loads
some of the gems as root (rack etc).
Ohad
···
On Sun, Mar 4, 2012 at 2:22 PM, Greg Sutcliffe wrote:
> On 4 March 2012 12:14, Ohad Levy wrote:
>> On Sun, Mar 4, 2012 at 12:59 PM, Greg Sutcliffe
>>
>> Git install makes sense, and in the original module (if you look
>> though the history) we had install via tar as well.
>> Why not simply use the git module to install git? :)
>
> Yeah, that'll work. I blame not having any coffee when I wrote the OP :P
>
>> as far as it goes for bundler, you could do the same logic, e.g. if
>> its a know os with bundler, use it, other wise, use the gem provider.
>
> Might just start with gems for simplicity - I can use an Exec to run
> bundle install
> as the correct user, which might cut down a *lot* of our gem issues.
