Development puppet master to test big changes (forced envs)

Hi everybody,

A thing we are running into now and then is a way to test big puppet
changes, like switching modules. For instance, we now are using a
munin-module that doesn't really fit our needs. There are 2 ways to fix
this situation: improve the current module, or switch to a different one
that suits our needs better. In this case we decided to go for a
different module. Now there is some testing you can do, use this module
on a fresh server and see how it behaves. That is all nice and well, but
at some point you want to see what will happen if you switch those
modules on a production server. So what you can do is disable the puppet
service on all servers using this configuration, roll out the change, do
a puppet test run on one of them (–noop), then maybe another and if all
looks well you start puppet again on all servers.
There is another way this can be done, and this is what we are currently
using:

We have a development puppet master, where we all have our own envs, so
I recreate a production env on this server, and on a production machine
i say puppet agent -t --noop --server <devserver> --environment <devenv>
With puppet 2, this works but with puppet 3 it won't, because in foreman
we have enc_environment set to true, and puppet 3 enforces the env it
gets from ENC. The way we currently workaround this is by adding a line
in /etc/puppet/node.rb:
result = result.gsub /^ environment:.*/, ''

How do others solve this issue? Is something like this (going to be)
supported in Foreman?

··· -- Sander

> Hi everybody,
>
> A thing we are running into now and then is a way to test big puppet
> changes, like switching modules. For instance, we now are using a
> munin-module that doesn't really fit our needs. There are 2 ways to fix
> this situation: improve the current module, or switch to a different one
> that suits our needs better. In this case we decided to go for a
> different module. Now there is some testing you can do, use this module
> on a fresh server and see how it behaves. That is all nice and well, but
> at some point you want to see what will happen if you switch those
> modules on a production server. So what you can do is disable the puppet
> service on all servers using this configuration, roll out the change, do
> a puppet test run on one of them (–noop), then maybe another and if all
> looks well you start puppet again on all servers.
> There is another way this can be done, and this is what we are currently
> using:
>
> We have a development puppet master, where we all have our own envs, so
> I recreate a production env on this server, and on a production machine
> i say puppet agent -t --noop --server <devserver> --environment <devenv>
> With puppet 2, this works but with puppet 3 it won't, because in foreman
> we have enc_environment set to true, and puppet 3 enforces the env it
> gets from ENC. The way we currently workaround this is by adding a line
> in /etc/puppet/node.rb:
> result = result.gsub /^ environment:.*/, ''
>
> How do others solve this issue? Is something like this (going to be)
> supported in Foreman?
>

You can turn off the env listing in the yaml output, see more --> settings.

Ohad

··· On Mon, Mar 18, 2013 at 12:17 PM, Sander Hoentjen wrote:


Sander


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/groups/opt_out.

Hi Ohad,

I know this, and I like this setting turned on for all puppetmasters.
There is just one puppetmaster where I would like to have this turned off.

··· On 03/18/2013 08:30 PM, Ohad Levy wrote: > > > On Mon, Mar 18, 2013 at 12:17 PM, Sander Hoentjen > wrote: > > Hi everybody, > > A thing we are running into now and then is a way to test big puppet > changes, like switching modules. For instance, we now are using a > munin-module that doesn't really fit our needs. There are 2 ways to fix > this situation: improve the current module, or switch to a different one > that suits our needs better. In this case we decided to go for a > different module. Now there is some testing you can do, use this module > on a fresh server and see how it behaves. That is all nice and well, but > at some point you want to see what will happen if you switch those > modules on a production server. So what you can do is disable the puppet > service on all servers using this configuration, roll out the change, do > a puppet test run on one of them (--noop), then maybe another and if all > looks well you start puppet again on all servers. > There is another way this can be done, and this is what we are currently > using: > > We have a development puppet master, where we all have our own envs, so > I recreate a production env on this server, and on a production machine > i say puppet agent -t --noop --server --environment > With puppet 2, this works but with puppet 3 it won't, because in foreman > we have enc_environment set to true, and puppet 3 enforces the env it > gets from ENC. The way we currently workaround this is by adding a line > in /etc/puppet/node.rb: > result = result.gsub /^ environment:.*/, '' > > How do others solve this issue? Is something like this (going to be) > supported in Foreman? > > > You can turn off the env listing in the yaml output, see more --> settings.

> >
> >
> >
> > Hi everybody,
> >
> > A thing we are running into now and then is a way to test big puppet
> > changes, like switching modules. For instance, we now are using a
> > munin-module that doesn't really fit our needs. There are 2 ways to
> fix
> > this situation: improve the current module, or switch to a different
> one
> > that suits our needs better. In this case we decided to go for a
> > different module. Now there is some testing you can do, use this
> module
> > on a fresh server and see how it behaves. That is all nice and well,
> but
> > at some point you want to see what will happen if you switch those
> > modules on a production server. So what you can do is disable the
> puppet
> > service on all servers using this configuration, roll out the
> change, do
> > a puppet test run on one of them (–noop), then maybe another and if
> all
> > looks well you start puppet again on all servers.
> > There is another way this can be done, and this is what we are
> currently
> > using:
> >
> > We have a development puppet master, where we all have our own envs,
> so
> > I recreate a production env on this server, and on a production
> machine
> > i say puppet agent -t --noop --server <devserver> --environment
> <devenv>
> > With puppet 2, this works but with puppet 3 it won't, because in
> foreman
> > we have enc_environment set to true, and puppet 3 enforces the env it
> > gets from ENC. The way we currently workaround this is by adding a
> line
> > in /etc/puppet/node.rb:
> > result = result.gsub /^ environment:.*/, ''
> >
> > How do others solve this issue? Is something like this (going to be)
> > supported in Foreman?
> >
> >
> > You can turn off the env listing in the yaml output, see more -->
> settings.
>
> Hi Ohad,
>
> I know this, and I like this setting turned on for all puppetmasters.
> There is just one puppetmaster where I would like to have this turned off.
>

Then your best way would be to remove that in the ENC script for that
master.

Ohad

··· On Tue, Mar 19, 2013 at 10:45 AM, Sander Hoentjen wrote: > On 03/18/2013 08:30 PM, Ohad Levy wrote: > > On Mon, Mar 18, 2013 at 12:17 PM, Sander Hoentjen > > 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/groups/opt_out.

Is this something that would be acceptible as an upstream patch, or
should I carry these changes locally?

··· On 03/19/2013 09:53 AM, Ohad Levy wrote: > > > On Tue, Mar 19, 2013 at 10:45 AM, Sander Hoentjen > wrote: > > On 03/18/2013 08:30 PM, Ohad Levy wrote: > > > > > > On Mon, Mar 18, 2013 at 12:17 PM, Sander Hoentjen > <sander@hoentjen.eu > > <mailto:sander@hoentjen.eu >> wrote: > > > > Hi everybody, > > > > A thing we are running into now and then is a way to test big > puppet > > changes, like switching modules. For instance, we now are using a > > munin-module that doesn't really fit our needs. There are 2 > ways to fix > > this situation: improve the current module, or switch to a > different one > > that suits our needs better. In this case we decided to go for a > > different module. Now there is some testing you can do, use > this module > > on a fresh server and see how it behaves. That is all nice and > well, but > > at some point you want to see what will happen if you switch those > > modules on a production server. So what you can do is disable > the puppet > > service on all servers using this configuration, roll out the > change, do > > a puppet test run on one of them (--noop), then maybe another > and if all > > looks well you start puppet again on all servers. > > There is another way this can be done, and this is what we are > currently > > using: > > > > We have a development puppet master, where we all have our own > envs, so > > I recreate a production env on this server, and on a > production machine > > i say puppet agent -t --noop --server > --environment > > With puppet 2, this works but with puppet 3 it won't, because > in foreman > > we have enc_environment set to true, and puppet 3 enforces the > env it > > gets from ENC. The way we currently workaround this is by > adding a line > > in /etc/puppet/node.rb: > > result = result.gsub /^ environment:.*/, '' > > > > How do others solve this issue? Is something like this (going > to be) > > supported in Foreman? > > > > > > You can turn off the env listing in the yaml output, see more --> > settings. > > Hi Ohad, > > I know this, and I like this setting turned on for all puppetmasters. > There is just one puppetmaster where I would like to have this > turned off. > > > Then your best way would be to remove that in the ENC script for that > master. >

Mickael proposed this already and I turned it down as we had the central
Foreman setting for it:

https://github.com/theforeman/puppet-foreman/pull/42

As Ewoud pointed out on IRC, only needing it for one puppetmaster seems
a valid enough use case for us to include it. If you'd like to resubmit
Mickael's change and a parameter to enable the option in puppet.conf,
then I'd accept it.

Cheers,

··· On 19/03/13 10:50, Sander Hoentjen wrote: > On 03/19/2013 09:53 AM, Ohad Levy wrote: >> >> >> On Tue, Mar 19, 2013 at 10:45 AM, Sander Hoentjen > > wrote: >> Hi Ohad, >> >> I know this, and I like this setting turned on for all puppetmasters. >> There is just one puppetmaster where I would like to have this >> turned off. >> >> >> Then your best way would be to remove that in the ENC script for that >> master. >> > Is this something that would be acceptible as an upstream patch, or > should I carry these changes locally?


Dominic Cleal
Red Hat Engineering

https://github.com/theforeman/puppet-foreman/pull/42 looks like
something very similar, but was closed.

··· On Tue, Mar 19, 2013 at 11:50:56AM +0100, Sander Hoentjen wrote: > On 03/19/2013 09:53 AM, Ohad Levy wrote: > > > > > > On Tue, Mar 19, 2013 at 10:45 AM, Sander Hoentjen > > wrote: > > > > On 03/18/2013 08:30 PM, Ohad Levy wrote: > > > > > > > > > On Mon, Mar 18, 2013 at 12:17 PM, Sander Hoentjen > > <sander@hoentjen.eu > > > <mailto:sander@hoentjen.eu >> wrote: > > > > > > Hi everybody, > > > > > > A thing we are running into now and then is a way to test big > > puppet > > > changes, like switching modules. For instance, we now are using a > > > munin-module that doesn't really fit our needs. There are 2 > > ways to fix > > > this situation: improve the current module, or switch to a > > different one > > > that suits our needs better. In this case we decided to go for a > > > different module. Now there is some testing you can do, use > > this module > > > on a fresh server and see how it behaves. That is all nice and > > well, but > > > at some point you want to see what will happen if you switch those > > > modules on a production server. So what you can do is disable > > the puppet > > > service on all servers using this configuration, roll out the > > change, do > > > a puppet test run on one of them (--noop), then maybe another > > and if all > > > looks well you start puppet again on all servers. > > > There is another way this can be done, and this is what we are > > currently > > > using: > > > > > > We have a development puppet master, where we all have our own > > envs, so > > > I recreate a production env on this server, and on a > > production machine > > > i say puppet agent -t --noop --server > > --environment > > > With puppet 2, this works but with puppet 3 it won't, because > > in foreman > > > we have enc_environment set to true, and puppet 3 enforces the > > env it > > > gets from ENC. The way we currently workaround this is by > > adding a line > > > in /etc/puppet/node.rb: > > > result = result.gsub /^ environment:.*/, '' > > > > > > How do others solve this issue? Is something like this (going > > to be) > > > supported in Foreman? > > > > > > > > > You can turn off the env listing in the yaml output, see more --> > > settings. > > > > Hi Ohad, > > > > I know this, and I like this setting turned on for all puppetmasters. > > There is just one puppetmaster where I would like to have this > > turned off. > > > > > > Then your best way would be to remove that in the ENC script for that > > master. > > > Is this something that would be acceptible as an upstream patch, or > should I carry these changes locally?