Hi,
I read that foreman is able to use dynamic puppet environments taken from a
git repository. I am interested in such a workflow but I can't find
information on how to set this up.
My first try was to check out different branches from our repo to some of
the environment paths present on the foreman but the results were not
sattisfying. Foreman saw the environments and the classes in each but mixed
them up if they had the same name. This is not what I expected ;-/
Does anyone have some resources on how to set this up correctly? I saw many
options on this in the interactive foreman-installer but how do they work
together?
I am on foreman 1.6.3
Thanks for any help!
Regards
Jochen
You're pretty much correct. I use a git post-recieve hook to check out
the repo into /etc/puppet/environments after each push, and I manually
import the classes in Foreman when required (Foreman only cares about
the class names and parameters, after all, not the actual puppet
code). You could auto-run the rake task for import if you are brave 
As for the collisions, it's known that Foreman doesn't do a great job
when the same class is in different environments and has different
class parameters in each environment. This is an issue while
developing new classes, I agree, but once your input parameters are
stable, Foreman should happily track what classes are available in
which environments, and offer the correct list to choose from when
configuring hosts.
I'm pretty sure there's already an open issue for the parameter
collision, although I'm struggling to find it just now
Greg
···
On 9 December 2014 at 16:20, Jochen Haeberle wrote:
> Hi,
>
> I read that foreman is able to use dynamic puppet environments taken from a
> git repository. I am interested in such a workflow but I can't find
> information on how to set this up.
>
> My first try was to check out different branches from our repo to some of
> the environment paths present on the foreman but the results were not
> sattisfying. Foreman saw the environments and the classes in each but mixed
> them up if they had the same name. This is not what I expected ;-/
Hi Greg,
thanks for the quick reply,
should Foreman be able to do set this up all by itself? There are some settings in the foreman-installer that suggest such thing…
and how about the the dynamic environments? As I understand the concept, environments are created on the fly based on git branches… so you could create a feature branch and this would automagically show up in foreman as an environment…
You say "the" rake task… is this available already or would I have to build one? I am not much of a Ruby-Guy unfortunately…
Regards
Jochen
···
> Am 09.12.2014 um 17:30 schrieb Greg Sutcliffe :
> You're pretty much correct. I use a git post-recieve hook to check out
> the repo into /etc/puppet/environments after each push, and I manually
> import the classes in Foreman when required (Foreman only cares about
> the class names and parameters, after all, not the actual puppet
> code). You could auto-run the rake task for import if you are brave :)
>
> As for the collisions, it's known that Foreman doesn't do a great job
> when the same class is in different environments *and* has different
> class parameters in each environment. This is an issue while
> developing new classes, I agree, but once your input parameters are
> stable, Foreman should happily track what classes are available in
> which environments, and offer the correct list to choose from when
> configuring hosts.
>
> I'm pretty sure there's already an open issue for the parameter
> collision, although I'm struggling to find it just now :)
>
> Greg
> Hi Greg,
>
> thanks for the quick reply,
>
> should Foreman be able to do set this up all by itself? There are some settings in the foreman-installer that suggest such thing…
There's a git parameter to the puppet module which should set up a git
repo in /var/lib/puppet and enable the post-receive hook
> and how about the the dynamic environments? As I understand the concept, environments are created on the fly based on git branches… so you could create a feature branch and this would automagically show up in foreman as an environment…
They'll show up automatically as environments in Puppet - to get them
into Foreman, you need to import them via the UI or the rake task
(which could potentially be scripted)
> You say "the" rake task… is this available already or would I have to build one? I am not much of a Ruby-Guy unfortunately…
Try "foreman-rake puppet:import:puppet_classes" or "foreman-rake -T"
for a list of all tasks.
Hope that helps,
Greg
···
On 9 December 2014 at 17:11, Jochen Häberle wrote:
Hi Greg,
thanks again!
>
>> Hi Greg,
>>
>> thanks for the quick reply,
>>
>> should Foreman be able to do set this up all by itself? There are some settings in the foreman-installer that suggest such thing…
>
> There's a git parameter to the puppet module which should set up a git
> repo in /var/lib/puppet and enable the post-receive hook
Do you speak of the foreman-installer or do you suggest using the foreman/puppet-puppet module? https://github.com/theforeman/puppet-puppet
I am still a bit shy mangling with my foreman-host, especially with puppet, as I do not really grasp how foreman is installed by puppet and what will break when I throw my own puppet classes at the same host…
>
>> and how about the the dynamic environments? As I understand the concept, environments are created on the fly based on git branches… so you could create a feature branch and this would automagically show up in foreman as an environment…
>
> They'll show up automatically as environments in Puppet - to get them
> into Foreman, you need to import them via the UI or the rake task
> (which could potentially be scripted)
>
>> You say "the" rake task… is this available already or would I have to build one? I am not much of a Ruby-Guy unfortunately…
>
> Try "foreman-rake puppet:import:puppet_classes" or "foreman-rake -T"
> for a list of all tasks.
Cool, thanks! Is there any documentation on all this available somewhere that I did miss up to now???
> Hope that helps,
> Greg
A lot, thanks!
Jochen
···
> Am 09.12.2014 um 19:49 schrieb Greg Sutcliffe :
> On 9 December 2014 at 17:11, Jochen Häberle wrote:
>> There's a git parameter to the puppet module which should set up a git
>> repo in /var/lib/puppet and enable the post-receive hook
>
> Do you speak of the foreman-installer or do you suggest using the foreman/puppet-puppet module? https://github.com/theforeman/puppet-puppet
Both. The installer uses that module (and others) to do the setup of
your host, and there is no difference between running them from the
commandline (we use a library called Kafo to turn puppet classes into
cmdline apps) and running them from a puppetmaster. If you look in
/etc/foreman-installer you'll see an answers file that contains all
the parameters passed to the modules, which can be useful if you want
to import the modules into your puppet master to ensure the foreman
server stays correctly configured.
> I am still a bit shy mangling with my foreman-host, especially with puppet, as I do not really grasp how foreman is installed by puppet and what will break when I throw my own puppet classes at the same host…
That's just a matter of testing If you're not already familiar with
"puppet agent -t --noop" I'd suggest giving it a try, it's great for
testing manifest changes.
>> Try "foreman-rake puppet:import:puppet_classes" or "foreman-rake -T"
>> for a list of all tasks.
>
> Cool, thanks! Is there any documentation on all this available somewhere that I did miss up to now???
I don't think so (rake -T is fairly comprehensive), although the
notable ones get mentioned in various places in the manual.
Greg
···
On 9 December 2014 at 21:46, Jochen Häberle wrote:
Hi Greg,
>
>>> There's a git parameter to the puppet module which should set up a git
>>> repo in /var/lib/puppet and enable the post-receive hook
>>
>> Do you speak of the foreman-installer or do you suggest using the foreman/puppet-puppet module? https://github.com/theforeman/puppet-puppet
>
> Both. The installer uses that module (and others) to do the setup of
> your host, and there is no difference between running them from the
> commandline (we use a library called Kafo to turn puppet classes into
> cmdline apps) and running them from a puppetmaster. If you look in
> /etc/foreman-installer you'll see an answers file that contains all
> the parameters passed to the modules, which can be useful if you want
> to import the modules into your puppet master to ensure the foreman
> server stays correctly configured.
I guess that's the way I will head - thanks!
> I am still a bit shy mangling with my foreman-host, especially with puppet, as I do not really grasp how foreman is installed by puppet and what will break when I throw my own puppet classes at the same host…
>
> That's just a matter of testing If you're not already familiar with
> "puppet agent -t --noop" I'd suggest giving it a try, it's great for
> testing manifest changes.
I guess the feeling will get better when the foreman-puppet class is in place and I can further expand on that in vagrant.
Thanks again for all the help.
Regards
Jochen
···
> Am 10.12.2014 um 22:57 schrieb Greg Sutcliffe :
> On 9 December 2014 at 21:46, Jochen Häberle wrote:
