Puppet users - Jan 2010 - Method for selecting between different versions of the same class?

Here''s my situation: I''ve got two groups of machines, one
where I have root
access and one where I don''t (don''t ask...).  The class to
provide
particular functionality for a machine where I have root access ends up
looking a lot different than the class for when I don''t.  The question
is
how to organize this.

One option is just to put a big if { } else { } block in each class, which
does work, but feels ugly to me, which lead me to this idea.

In my module''s manifest/init.pp, I have:

import "common/*.pp"

# $id is the user id of the person running puppet... so root in one case and
my regular user in the other

case $id {
  "root": {
     warning("including root...")
     import "root/*.pp"
   }
   "onebus": {
     warning("including onebus...")
     import "onebus/*.pp"
   }
}

I then have a root/someclass.pp and a onebus/someclass.pp, both of which
declare the someclass class (they both have same name).

I was hoping the case statement would selectively include the appropriate
class definitions (as a sanity check, I only see one "including ..."
warning
in the logs, as hoped).  However, it seems like the import statements are
executing regardless and both versions of someclass are being included,
(warning debug messages in both the class definitions fire) which obviously
doesn''t help me.

I''m curious why the above doesn''t work.  I''ll
probably go back to individual
case statements within the classes themselves.

Is there some way to pull this off with class inheritance perhaps?

Thanks,
Brian


-- 

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

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

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

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

On 01/16/2010 12:14 AM, Brian Ferris wrote:
> Here''s my situation: I''ve got two groups of machines, one
where I have
> root access and one where I don''t (don''t ask...).  The
class to
> provide particular functionality for a machine where I have root 
> access ends up looking a lot different than the class for when I 
> don''t.  The question is how to organize this.
>
> One option is just to put a big if { } else { } block in each class, 
> which does work, but feels ugly to me, which lead me to this idea.
>
> In my module''s manifest/init.pp, I have:
>
> import "common/*.pp"
>
> # $id is the user id of the person running puppet... so root in one 
> case and my regular user in the other
>
> case $id {
>   "root": {
>      warning("including root...")
>      import "root/*.pp"
>    }
>    "onebus": {
>      warning("including onebus...")
>      import "onebus/*.pp"
>    }
> }
Imports for this looks like a hack to me.
>
> I then have a root/someclass.pp and a onebus/someclass.pp, both of 
> which declare the someclass class (they both have same name).
>
> I was hoping the case statement would selectively include the 
> appropriate class definitions (as a sanity check, I only see one 
> "including ..." warning in the logs, as hoped).  However, it
seems
> like the import statements are executing regardless and both versions 
> of someclass are being included, (warning debug messages in both the 
> class definitions fire) which obviously doesn''t help me.
>
> I''m curious why the above doesn''t work.  I''ll
probably go back to
> individual case statements within the classes themselves.
>
> Is there some way to pull this off with class inheritance perhaps?
>
I would go for this pattern (but this is done for each class as opposed 
to all of them)

class myprogram
{

  case $id {
   "root": {
      include myprogram::root
    }
    "onebus": {
      include myprogram::onebus
    }
  }
}

class myprogram::base
{
     ... common defs go here...
}
class myprogram::root inherits myprogram::base
{
     ....root defs go here...
}
class myprogram::onebus inherits myprogram::base
{
      ....onebus goes here....
}



As an alternartive you may use environments. And you will have 3 module 
dirs 1 root, 1 onebus, 1 common. Common is for both environments.
But I still find it better to use the above pattern.



Silviu

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> As an alternartive you may use environments. And you will have 3 module
> dirs 1 root, 1 onebus, 1 common. Common is for both environments.
> But I still find it better to use the above pattern.
I would also recommend to go for environments. Using git you can easily
merge among these and you name things everywhere the same.

cheers pete
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktS+asACgkQbwltcAfKi395lQCdGfEKUkj4Pifoq13tSskOciJB
UUUAn0LusOQq8io2inmoWgdECKia0h1h
=1d8X
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.