Question about reusing classes/modules

[Tony C]

Hello Everyone,

I'm still pretty new with puppet so please bare with me. I tried
searching and I'm pretty sure I've ready my answer but I'm not sure if
I'm going down the right path just yet.

My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
of these environments lives in 2 sites, LA and NY. I have 5
applications that are site and env specific.

I want to use puppet to template-ize the config files that is required
for each env, per site, per app, so 40 files.

The config file is basically key=value pairs. Here's a simple example
of what each file may look like:

site=LA
env=Dev
app=App1
masterServer=host1
clientServer1=host2
clientServer2=host3

Even more interesting, the the config files have the naming structure
app_site_env.properites. So lots of the same, over and over again,
just different values. Let's say the machine managing these files is
called

node configbox

My first idea was to create an erb of that config file, use
parameterized classes and variables to fill in the blanks, some if/
else logic and the populate each file. That works. The thing is, I
will have 40 modules with the same init.pp and anytime I update
something, I'd have to make that change across 39 more modules!

What is the best strategy to reuse a base module, and then apply
specific values on top of that base module based on some condition? Do
I use inherit or subclasses?

config
config::app and then in that config::app define what I need to replace
depending on site and env?

Sorry for the long winded and confusing post.

Thanks so much!

Tony

[krish]

> My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
> of these environments lives in 2 sites, LA and NY. I have 5
> applications that are site and env specific.
>
> I want to use puppet to template-ize the config files that is required
> for each env, per site, per app, so 40 files.
>
> The config file is basically key=value pairs. Here's a simple example
> of what each file may look like:
>
> site=LA
> env=Dev
> app=App1
> masterServer=host1
> clientServer1=host2
> clientServer2=host3
>

How about having these key value pairs in site.pp with a case environment
Then they become global to all modules.

--
Krish
olindata.com

[Eric Shamow]

I would avoid this approach - global variables aren't a good idea.

Hiera would be a better approach:

http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchical_data_store.php

http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php

-Eric

-- 

Eric Shamow

Professional Services

http://puppetlabs.com/

(c)631.871.6441

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[ad]

I'd recommend looking into using an external node classifier. I like
Foreman, though it doesn't support parameterized classes yet (there is
an easy workaround though).

Adam

[Tony C]

Thanks for the assistance. I checked out Hiera and to be honest, that
is really way out of my league right now. When I get there, I will
definitely be looking into it, because I know I will get there soon,
unless you want to give me the 5 minutes selling pitch?
=)

I have been reading the style guide and the best practices pages and
came up with this model: (using CONFIG in caps to represent it as my
base module)

Since I have to manage 40 files all with different values, I just
created a subclass called
CONFIG::show1_prod_LA. In the show1_prod_LA.pp file, I created all my
specific key=value pairs, and then I included config.

in the CONFIG init.pp i have:

file { "/tmp/${app}_${site}_${env}.properites":
ensure => present,
content => template("mymodule/
template.properties.erb"),

So basically I am reusing the same class CONFIG but having each
subclass over write the values. This worked for the first subclass. I
tried creating a second subclass, called CONFIG:show1_prod_NY. This
subclass has the same keys, but obviously different values.

In my site.pp I have this:

node mydesktop{
include CONFIG::show1_prod_LA:
include CONFIG::show1_prod_NY

}

My problem is, only the first include "include
CONFIG::show1_prod_LA:" runs. Am I completely using puppet in a way
I'm not supposed to?

On Feb 11, 5:48 pm, Eric Shamow <e...@puppetlabs.com> wrote:
> I would avoid this approach - global variables aren't a good idea.
>
> Hiera would be a better approach:
>

> http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchic...http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php
>
> -Eric
>
> --
>
> Eric Shamow
> Professional Serviceshttp://puppetlabs.com/

> (c)631.871.6441
>
>
>
>
>
>
>
> On Saturday, February 11, 2012 at 7:08 PM, krish wrote:
> > > My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
> > > of these environments lives in 2 sites, LA and NY. I have 5
> > > applications that are site and env specific.
>
> > > I want to use puppet to template-ize the config files that is required
> > > for each env, per site, per app, so 40 files.
>
> > > The config file is basically key=value pairs. Here's a simple example
> > > of what each file may look like:
>
> > > site=LA
> > > env=Dev
> > > app=App1
> > > masterServer=host1
> > > clientServer1=host2
> > > clientServer2=host3
>
> > How about having these key value pairs in site.pp with a case environment
> > Then they become global to all modules.
>
> > --
> > Krish

> > olindata.com (http://olindata.com)

>
> > --
> > You received this message because you are subscribed to the Google Groups "Puppet Users" group.

> > To post to this group, send email to puppet...@googlegroups.com (mailto:puppet...@googlegroups.com).
> > To unsubscribe from this group, send email to puppet-users...@googlegroups.com (mailto:puppet-users...@googlegroups.com).

[Tony C]

node classification seems essential to growing out my puppet
infrastructure and to do some neat things with it.

Can someone post a very simple example of how I can leverage external
node classification in my scenario? If this warrants another thread,
please let me know.

Thanks everyone.

[Kenneth Lo]

Eric: 

Can you elborate on why global variables is a bad idea? Most of my environment's key-value pairs are set via dashboard as ENC, which I think are all global.

--KL 

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

[Brian Gupta]

I would say Global vars aren't necessarily evil. However, they ideally fit into a hierarchical structure, where one can have variable scoping with an ability to override global vars with more tightly scoped local overrides.

Foreman, and Hiera support the ability to set the same variable at multiple hierarchical levels and have the most "local" variable scoping override the global. Think Global vars, datacenter vars, domain specific vars, subnet vars, host vars, hostgroup vars, etc.

(Folks please correct me if I explained this incorrectly.)

-Brian

[Tony C]

My own problem is that once I setup a variable, I can't reassign the
variable again in the same module. Based on what I saw in the in
dashboard, there is a conflict.

I think I over engineered this piece of my project. I am better off
manually creating 40 properties values, treating all of the values as
static points of truth, and then just using FILE in 1 huge manifest.

Thanks for all your help. It has led me to leverage the Dashboard as
an ENC.

On Feb 13, 7:56 pm, Brian Gupta <brian.gu...@brandorr.com> wrote:
> I would say Global vars aren't necessarily evil. However, they ideally fit
> into a hierarchical structure, where one can have variable scoping with an
> ability to override global vars with more tightly scoped local overrides.
>
> Foreman, and Hiera support the ability to set the same variable at
> multiple hierarchical levels and have the most "local" variable scoping
> override the global. Think Global vars, datacenter vars, domain specific
> vars, subnet vars, host vars, hostgroup vars, etc.
>
> (Folks please correct me if I explained this incorrectly.)
>
> -Brian
>
>
>
>
>
>
>
>
>
> On Mon, Feb 13, 2012 at 12:14 PM, Kenneth Lo <k...@paydiant.com> wrote:
> >  Eric:
>
> >  Can you elborate on why global variables is a bad idea? Most of my
> > environment's key-value pairs are set via dashboard as ENC, which I think
> > are all global.
>
> >  --KL
>

> >   From: Eric Shamow <e...@puppetlabs.com>
> > Reply-To: "puppet...@googlegroups.com" <puppet...@googlegroups.com>
> > Date: Sat, 11 Feb 2012 20:48:24 -0500
> > To: "puppet...@googlegroups.com" <puppet...@googlegroups.com>
> > Subject: Re: [Puppet Users] Question about reusing classes/modules
>
> >  I would avoid this approach - global variables aren't a good idea.
>
> >  Hiera would be a better approach:
>

> >http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchic...

> <http://aws.amazon.com/solutions/solution-providers/brandorr/>

[Tony C]

http://www.craigdunn.org/2011/10/puppet-configuration-variables-and-hiera/

Hiera it is! Exactly what I needed. i just need a bit more explaining.

On Feb 11, 5:48 pm, Eric Shamow <e...@puppetlabs.com> wrote:

> I would avoid this approach - global variables aren't a good idea.
>
> Hiera would be a better approach:
>

> http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchic...http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php
>
> -Eric
>
> --
>
> Eric Shamow
> Professional Serviceshttp://puppetlabs.com/

> (c)631.871.6441
>
>
>
>
>
>
>
> On Saturday, February 11, 2012 at 7:08 PM, krish wrote:
> > > My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
> > > of these environments lives in 2 sites, LA and NY. I have 5
> > > applications that are site and env specific.
>
> > > I want to use puppet to template-ize the config files that is required
> > > for each env, per site, per app, so 40 files.
>
> > > The config file is basically key=value pairs. Here's a simple example
> > > of what each file may look like:
>
> > > site=LA
> > > env=Dev
> > > app=App1
> > > masterServer=host1
> > > clientServer1=host2
> > > clientServer2=host3
>
> > How about having these key value pairs in site.pp with a case environment
> > Then they become global to all modules.
>
> > --
> > Krish

> > olindata.com (http://olindata.com)

>
> > --
> > You received this message because you are subscribed to the Google Groups "Puppet Users" group.

> > To post to this group, send email to puppet...@googlegroups.com (mailto:puppet...@googlegroups.com).
> > To unsubscribe from this group, send email to puppet-users...@googlegroups.com (mailto:puppet-users...@googlegroups.com).