thr3ads.net - Puppet users - [Puppet Users] parameterized classes and variable inheritance [Mar 2011]

If this information is useful, please help other people find it:
Share via:

Ashley Gould

2011-Mar-17 23:03 UTC

[Puppet Users] parameterized classes and variable inheritance

I am exploring usage of parameterized classes.  I hit a wall when
trying to override values of parameters in a node definition that 
inherits the class from a parent node.  Is there a way to do this,
or must I include the class only in the child node?

I''m hoping to avoid using subclasses, because there would have to 
be oodles of them to accomodate the all the variations between nodes.


node default {
    class { sudoers: }
}

node ''sl11lab02'' inherits default {

    # this runs but does nothing
    Class[sudoers] { additional_rules => [ "$rules_uas" ] }

    # this errors with "Cannot assign to variables in other
namespaces"
    #$sudoers::additional_rules = [ "$rules_uas" ]

    # this errors with "Class[Sudoers] is already defined"
    #class { sudoers: additional_rules => [ "$rules_uas" ] }
}

class sudoers (
    $default_rules    = "$rules_unixgroup",
    $additional_rules = [ "" ]
    ) {

    file { "/tmp/sudoers":
        owner   => root, group => root, mode => 440,
        content => template("sudoers/sudoers.erb"),
        notify  => Exec["check-sudoers"],
    }

    exec { "check-sudoers":
        command => "/usr/sbin/visudo -cf /tmp/sudoers && cp
/tmp/sudoers /etc/sudoers",
        refreshonly => true,
    }

}








-- 

-ashley

Did you try poking at it with a stick?

-- 
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.

Guillaume Rousse

2011-Mar-18 10:41 UTC

head link

Re: [Puppet Users] parameterized classes and variable inheritance

Le 18/03/2011 00:03, Ashley Gould a écrit :> I am exploring usage of parameterized classes.  I hit a wall when
> trying to override values of parameters in a node definition that 
> inherits the class from a parent node.  Is there a way to do this,
> or must I include the class only in the child node?I''m also facing the same issue, except I''m rather interested
in the
result (managing specific case of a policy applied everywhere from basic
node definition) rather than the exact way to achieve it (parameterized
classes, defined type, whatever).

This is true for instance for ntp, ssh, syslog, etc... Basically every
kind of service running as server on all machines with the same
configuration excepted in a specific node, the master (smtp or ssh
gateway, ntp master, etc...).

Currently, I''m managing this by hardcoding conditional in the class,
but
I don''t like mixing the semantic of "how to run a service"
with "how do
map my services to my infrastructure".

node "basenode" {
    include ntp::server
}

node "ntp.tld" inherits basenode {
}

class ntp::server {
    $servers = $hostname ? {
        ntp => ["ntp.foo", "ntp.bar",
"ntp.baz"],
        default => "ntp.tld"
    }
}

I could potentialy move the conditional into the "basenode"
definition,
which would achieve a bit more separation of concerns, but would be
quite ugly. What I''d really like would be some way to express:

node "basenode" {
    include ntp::server (with servers = "ntp.tld")
}

node "ntp.tld" inherits basenode {
    include ntp::server (with servers = ["ntp.foo",
"ntp.bar", "ntp.baz"])
}
-- 
BOFH excuse #82:

Yeah, yo mama dresses you funny and you need a mouse to delete files.

-- 
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.

jcbollinger

2011-Mar-18 18:15 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

On Mar 17, 6:03 pm, Ashley Gould <ago...@ucop.edu>
wrote:> I''m hoping to avoid using subclasses, because there would have to
> be oodles of them to accomodate the all the variations between nodes.
>
> node default {
>     class { sudoers: }
>
> }
>
> node ''sl11lab02'' inherits default {
>
>     # this runs but does nothing
>     Class[sudoers] { additional_rules => [ "$rules_uas" ] }
>
>     # this errors with "Cannot assign to variables in other
namespaces"
>     #$sudoers::additional_rules = [ "$rules_uas" ]
>
>     # this errors with "Class[Sudoers] is already defined"
>     #class { sudoers: additional_rules => [ "$rules_uas" ] }
>
> }
Node inheritance is not the same as class inheritance.  Only the
latter allows you to override resource properties, and I''m not sure
whether even that allows you to override class parameters.  I had
thought not.

If you have many nodes with various small differences between them,
then perhaps it''s time to look into an external node classifier.
Alternatively, make your classes smarter: instead of parameterizing
them, put the erstwhile parameter-selection logic inside them.


John

-- 
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.

Ashley Gould

2011-Mar-19 02:01 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

On Fri, Mar 18, 2011 at 11:15:56AM -0700, jcbollinger
wrote:> 
> 
> On Mar 17, 6:03 pm, Ashley Gould <ago...@ucop.edu> wrote:
> > I''m hoping to avoid using subclasses, because there would
have to
> > be oodles of them to accomodate the all the variations between nodes.
> >
> > node default {
> >     class { sudoers: }
> >
> > }
> >
> > node ''sl11lab02'' inherits default {
> >
> >     # this runs but does nothing
> >     Class[sudoers] { additional_rules => [ "$rules_uas" ]
}
> >
> >     # this errors with "Cannot assign to variables in other
namespaces"
> >     #$sudoers::additional_rules = [ "$rules_uas" ]
> >
> >     # this errors with "Class[Sudoers] is already defined"
> >     #class { sudoers: additional_rules => [ "$rules_uas"
] }
> >
> > }
> 
> Node inheritance is not the same as class inheritance.  Only the
> latter allows you to override resource properties, and I''m not
sure
> whether even that allows you to override class parameters.  I had
> thought not.
> 
> If you have many nodes with various small differences between them,
> then perhaps it''s time to look into an external node classifier.
> Alternatively, make your classes smarter: instead of parameterizing
> them, put the erstwhile parameter-selection logic inside them.

You touched the heart of the matter:  Is there a way to override
class parameters?


-- 
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.

Nigel Kersten

2011-Mar-19 15:56 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

On Fri, Mar 18, 2011 at 7:01 PM, Ashley Gould <agould@ucop.edu>
wrote:> On Fri, Mar 18, 2011 at 11:15:56AM -0700, jcbollinger wrote:
>>
>>
>> On Mar 17, 6:03 pm, Ashley Gould <ago...@ucop.edu> wrote:
>> > I''m hoping to avoid using subclasses, because there would
have to
>> > be oodles of them to accomodate the all the variations between
nodes.
>> >
>> > node default {
>> >     class { sudoers: }
>> >
>> > }
>> >
>> > node ''sl11lab02'' inherits default {
>> >
>> >     # this runs but does nothing
>> >     Class[sudoers] { additional_rules => [
"$rules_uas" ] }
>> >
>> >     # this errors with "Cannot assign to variables in other
namespaces"
>> >     #$sudoers::additional_rules = [ "$rules_uas" ]
>> >
>> >     # this errors with "Class[Sudoers] is already
defined"
>> >     #class { sudoers: additional_rules => [
"$rules_uas" ] }
>> >
>> > }
>>
>> Node inheritance is not the same as class inheritance.  Only the
>> latter allows you to override resource properties, and I''m not
sure
>> whether even that allows you to override class parameters.  I had
>> thought not.
>>
>> If you have many nodes with various small differences between them,
>> then perhaps it''s time to look into an external node
classifier.
>> Alternatively, make your classes smarter: instead of parameterizing
>> them, put the erstwhile parameter-selection logic inside them.
>
>
> You touched the heart of the matter:  Is there a way to override
> class parameters?

No. Once you''ve declared a class, you can''t declare it again
with
different parameters.

In fact, you can''t declare it again at all.

-- 
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.

Guillaume Rousse

2011-Mar-21 09:56 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

Le 18/03/2011 19:15, jcbollinger a écrit :> If you have many nodes with various small differences between them,
> then perhaps it''s time to look into an external node classifier.If I''m understand correctly, this just move the problem elsewhere
(potentially making it easier to solve), as the classifier will have to
manage parameters overriding itself.
-- 
BOFH excuse #192:

runaway cat on system.

-- 
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.

Bill Proud

2011-Mar-21 11:23 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

The following would work:

node default {
    class { sudoers: }
}

node ''sl11lab02'' {
    class { sudoers: additional_rules => [ "$rules_uas" ] }
}


On Mar 18, 12:03 am, Ashley Gould <ago...@ucop.edu>
wrote:> I am exploring usage of parameterized classes.  I hit a wall when
> trying to override values of parameters in a node definition that
> inherits the class from a parent node.  Is there a way to do this,
> or must I include the class only in the child node?
>
> I''m hoping to avoid using subclasses, because there would have to
> be oodles of them to accomodate the all the variations between nodes.
>
> node default {
>     class { sudoers: }
>
> }
>
> node ''sl11lab02'' inherits default {
>
>     # this runs but does nothing
>     Class[sudoers] { additional_rules => [ "$rules_uas" ] }
>
>     # this errors with "Cannot assign to variables in other
namespaces"
>     #$sudoers::additional_rules = [ "$rules_uas" ]
>
>     # this errors with "Class[Sudoers] is already defined"
>     #class { sudoers: additional_rules => [ "$rules_uas" ] }
>
> }
>
> class sudoers (
>     $default_rules    = "$rules_unixgroup",
>     $additional_rules = [ "" ]
>     ) {
>
>     file { "/tmp/sudoers":
>         owner   => root, group => root, mode => 440,
>         content => template("sudoers/sudoers.erb"),
>         notify  => Exec["check-sudoers"],
>     }
>
>     exec { "check-sudoers":
>         command => "/usr/sbin/visudo -cf /tmp/sudoers && cp
/tmp/sudoers /etc/sudoers",
>         refreshonly => true,
>     }
>
> }
>
> --
>
> -ashley
>
> Did you try poking at it with a stick?
-- 
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.

Guillaume Rousse

2011-Mar-21 12:10 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

Le 21/03/2011 10:56, Guillaume Rousse a écrit :> Le 18/03/2011 19:15, jcbollinger a écrit :
>> If you have many nodes with various small differences between them,
>> then perhaps it''s time to look into an external node
classifier.
> If I''m understand correctly, this just move the problem elsewhere
> (potentially making it easier to solve), as the classifier will have to
> manage parameters overriding itself.I just found a potential answer in list archive:
http://www.mail-archive.com/puppet-users@googlegroups.com/msg11122.html

The subtility is not to call the defined resource a second time, but to
refers to it:
Broken["message"] { value => "not " }
instead of
broken ( "message": value => "not" } }

I just tried the same example with parameterized classes, it doesn''t
work:

node default                    { class { message: value => ""    
} }
node "beria" inherits "default" { Class[message] { value
=> "not " } }
class message($value)           { notice("This is ${value}broken") }

So, defined type seems still more flexible than parameterized classes.
-- 
BOFH excuse #230:

Lusers learning curve appears to be fractal

-- 
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.

jcbollinger

2011-Mar-21 14:47 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

On Mar 21, 7:10 am, Guillaume Rousse <guillomovi...@gmail.com>
wrote:> Le 21/03/2011 10:56, Guillaume Rousse a crit :> Le 18/03/2011 19:15,
jcbollinger a crit :
> >> If you have many nodes with various small differences between
them,
> >> then perhaps it''s time to look into an external node
classifier.
> > If I''m understand correctly, this just move the problem
elsewhere
> > (potentially making it easier to solve), as the classifier will have
to
> > manage parameters overriding itself.
>
> I just found a potential answer in list
archive:http://www.mail-archive.com/puppet-users@googlegroups.com/msg11122.html
>
> The subtility is not to call the defined resource a second time, but to
> refers to it:
> Broken["message"] { value => "not " }
> instead of
> broken ( "message": value => "not" } }
Yes, this is resource overriding, which I mentioned earlier.  It can
be done only in a subclass of the class containing the definition of
the resource in question.  Inasmuch as the OP remarked that they
wanted to avoid subclasses, I think they are aware of this option and
find it unsuitable.
> I just tried the same example with parameterized classes, it
doesn''t work:
>
> node default                    { class { message: value => ""
    } }
> node "beria" inherits "default" { Class[message] {
value => "not " } }
> class message($value)           { notice("This is
${value}broken") }
>
> So, defined type seems still more flexible than parameterized classes.

Parameterized classes are not resources any more than ordinary classes
are, syntax similarity notwithstanding.  You cannot override the
parameters of a parameterized class.

Defined types are effectively custom resource types written in the
Puppet DSL instead of in Ruby.  Resources of such types behave like
resources of any built-in or custom type, so among other things, their
parameters can be overridden via subclasses.

I don''t think it''s fair to say that defined types are more
flexible
than parameterized classes, because the two features aren''t on the
same level.  On the other hand, I think that parameterized classes do
receive more attention than they deserve.  They solve certain
problems, but they also have limitations that plain classes do not
have.  In particular, ordinary classes'' idempotency and support for
multiple inclusion constitute a very powerful Puppet feature that
parameterized classes cannot (currently) provide.

I would not recommend anyone to use parameterized classes without
understanding exactly why they are doing so and what it may cost
them.  If the benefit justifies the cost, however, then go for it!

John

-- 
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.

hai wu

2011-Mar-21 17:20 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

I am going to use parameterized class together with extlookup, where
extlookup is used to provide different parameter value for different node
based on extlookup_precedence, the parameterized class needs to be declared
once in parent node, any issues you could forsee with this plan?

- Hai

On Mon, Mar 21, 2011 at 9:47 AM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
> On Mar 21, 7:10 am, Guillaume Rousse <guillomovi...@gmail.com> wrote:
> > Le 21/03/2011 10:56, Guillaume Rousse a crit :> Le 18/03/2011
19:15,
> jcbollinger a crit :
> > >> If you have many nodes with various small differences between
them,
> > >> then perhaps it''s time to look into an external node
classifier.
> > > If I''m understand correctly, this just move the problem
elsewhere
> > > (potentially making it easier to solve), as the classifier will
have to
> > > manage parameters overriding itself.
> >
> > I just found a potential answer in list archive:
> http://www.mail-archive.com/puppet-users@googlegroups.com/msg11122.html
> >
> > The subtility is not to call the defined resource a second time, but
to
> > refers to it:
> > Broken["message"] { value => "not " }
> > instead of
> > broken ( "message": value => "not" } }
>
> Yes, this is resource overriding, which I mentioned earlier.  It can
> be done only in a subclass of the class containing the definition of
> the resource in question.  Inasmuch as the OP remarked that they
> wanted to avoid subclasses, I think they are aware of this option and
> find it unsuitable.
>
> > I just tried the same example with parameterized classes, it
doesn''t
> work:
> >
> > node default                    { class { message: value =>
""     } }
> > node "beria" inherits "default" { Class[message] {
value => "not " } }
> > class message($value)           { notice("This is
${value}broken") }
> >
> > So, defined type seems still more flexible than parameterized classes.
>
>
> Parameterized classes are not resources any more than ordinary classes
> are, syntax similarity notwithstanding.  You cannot override the
> parameters of a parameterized class.
>
> Defined types are effectively custom resource types written in the
> Puppet DSL instead of in Ruby.  Resources of such types behave like
> resources of any built-in or custom type, so among other things, their
> parameters can be overridden via subclasses.
>
> I don''t think it''s fair to say that defined types are
more flexible
> than parameterized classes, because the two features aren''t on the
> same level.  On the other hand, I think that parameterized classes do
> receive more attention than they deserve.  They solve certain
> problems, but they also have limitations that plain classes do not
> have.  In particular, ordinary classes'' idempotency and support
for
> multiple inclusion constitute a very powerful Puppet feature that
> parameterized classes cannot (currently) provide.
>
> I would not recommend anyone to use parameterized classes without
> understanding exactly why they are doing so and what it may cost
> them.  If the benefit justifies the cost, however, then go for it!
>
>
> John
>
> --
> 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.
>
>
-- 
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.

jcbollinger

2011-Mar-21 18:17 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

On Mar 21, 4:56 am, Guillaume Rousse <guillomovi...@gmail.com>
wrote:> Le 18/03/2011 19:15, jcbollinger a crit :> If you have many nodes with
various small differences between them,
> > then perhaps it''s time to look into an external node
classifier.
>
> If I''m understand correctly, this just move the problem elsewhere
> (potentially making it easier to solve), as the classifier will have to
> manage parameters overriding itself.
I prefer to characterize the possible move to an external node
classifier as redefining the problem.  Rather than solving "how do I
override the parameters of a parameterized class", we can instead
focus on the higher-level problem "how do I assign the correct
parameters to my nodes'' classes?"  The external node classifier
would
indeed need to choose the correct parameters for each parameterized
class it assigns to each node, but that does not necessarily involve
any form of overriding.  This approach is one of those that makes
sense when no single hierarchy is sufficient to characterize your
nodes.

If an external node classifier is undesirable (which it may be for any
of several reasons), then some of these suggestions may help:
1. Flatten the node hierarchy.  The deeper the hierarchy, the more
likely it is that you will end up with a node that wants to be at two
different places in it.
2. Make classes self-contained as much as possible.  In particular, do
not use parameters to pass information that classes can determine for
themselves based on the available facts.
3. Don''t hesitate to make your classes smart, so that they adapt
resource declarations appropriately for your nodes.
4. Where possible, refactor common logic into ordinary classes that
multiple other classes and/or nodes can include, rather than into node
definitions.  This is a viable substitute for many of the uses to
which parameterized classes are put, but beware of variable scoping
issues that may arise.  It''s safest to rely only on facts.
5. Prefer to assign the correct classes to each node in the first
place, rather than relying on overriding.  On the other hand, DO
override resource properties (by including subclasses) where it makes
sense to do so.
6. Make sure your classes have well-defined scope and purpose, even if
this means you end up with many small classes.
7. Consider extlookup()

John

-- 
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.

Ashley Gould

2011-Mar-21 18:20 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

On Mon, Mar 21, 2011 at 07:47:14AM -0700, jcbollinger
wrote:> 
> Parameterized classes are not resources any more than ordinary classes
> are, syntax similarity notwithstanding.  You cannot override the
> parameters of a parameterized class.
> 
> Defined types are effectively custom resource types written in the
> Puppet DSL instead of in Ruby.  Resources of such types behave like
> resources of any built-in or custom type, so among other things, their
> parameters can be overridden via subclasses.
> 
> I don''t think it''s fair to say that defined types are
more flexible
> than parameterized classes, because the two features aren''t on the
> same level.  On the other hand, I think that parameterized classes do
> receive more attention than they deserve.  They solve certain
> problems, but they also have limitations that plain classes do not
> have.  In particular, ordinary classes'' idempotency and support
for
> multiple inclusion constitute a very powerful Puppet feature that
> parameterized classes cannot (currently) provide.
> 
> I would not recommend anyone to use parameterized classes without
> understanding exactly why they are doing so and what it may cost
> them.  If the benefit justifies the cost, however, then go for it!
> 
Please forgive my ignorance.  I find myself, a linux admin brought
up on howtos and books with animals on the cover, suddenly plunged
by puppet into a world of developers and computer scientists.  Could
you explain what is "idempotency" and "support for multiple
inclusion"?


-- 

-ashley

Did you try poking at it with a stick?

-- 
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.

Ashley Gould

2011-Mar-21 18:28 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

On Mon, Mar 21, 2011 at 04:23:40AM -0700, Bill Proud
wrote:> The following would work:
> 
> node default {
>     class { sudoers: }
> }
> 
> node ''sl11lab02'' {
>     class { sudoers: additional_rules => [ "$rules_uas" ] }
> }
> 
This does work, but I lose inheritance from node default.
In fact, this is my current work around.


-- 
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.

jcbollinger

2011-Mar-21 18:40 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

On Mar 21, 12:20 pm, hai wu <haiwu...@gmail.com>
wrote:> I am going to use parameterized class together with extlookup, where
> extlookup is used to provide different parameter value for different node
> based on extlookup_precedence, the parameterized class needs to be declared
> once in parent node, any issues you could forsee with this plan?
I think the problems are few for which parameterized classes are the
*best* solution.  Nevertheless the combination of parameterized
classes with extlookup() may be the *most expedient* solution
available at the moment.  It will very likely solve your problem.

There is some risk that you will run into trouble later as you
continue to add nodes or manage more aspects of your configurations.
In particular, if the number of distinct parameters you have to handle
increases as you scale up, then you may reach a point when the
parameters become a management problem of their own.

There are other possible problems associated with parameterized
classes, generally revolving around the fact that you can only include
them once.  Whether you are likely to run into any of them depends on
how and how much you use such classes.

Good Luck,

John

-- 
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.

jcbollinger

2011-Mar-21 20:05 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

On Mar 21, 1:20 pm, Ashley Gould <ago...@ucop.edu>
wrote:> Please forgive my ignorance.  I find myself, a linux admin brought
> up on howtos and books with animals on the cover, suddenly plunged
> by puppet into a world of developers and computer scientists.  Could
> you explain what is "idempotency" and "support for multiple
inclusion"?
Sorry, my bad.  The point is that you can include an ordinary class
multiple times on the same node (multiple inclusion), and the result
is exactly the same as if that class were included only once
(idempotency).  This can be important in a deep node inheritance
hierarchy, but it is more commonly important in situations where
classes include other classes.

For example, a common Puppet idiom is to create a "user" module
containing a "user::virtual" class in which virtual user resources are
declared for all system users.  Other classes then make decisions
about which users should actually be present on the system by
realizing subsets of those users (via Puppet''s "realize"
function or
<| |> syntax).  In my case, users are assigned to various research
groups, so I have a class for each group that realizes the users
associated with that group.  But those classes can only work if the
user::virtual class is included in the node''s catalog.  It would be
possible to address that problem by ensuring that each node explicitly
includes "user::virtual", but that''s clunky and subject to
breakage.
Instead, it''s better for each class that wants to realize users to
*itself* include user::virtual, which is possible and completely safe
provided that user::virtual is not parameterized.

Parameterized classes, on the other hand, can be included only once
per node, no matter what.  This is a substantial limitation on where
and how such classes can be used.

I hope that helps.

Cheers,

John

-- 
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.

Brian Gallew

2011-Mar-21 20:15 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

It has occurred to me that another way of doing this would be to use defines

  define kludge($sudo_add_rule=undef) {
    node { "${name}":
        class {sudoers: additional_rules => [$sudo_add_rule}}
     }  
  }

The beauty of this is that it gets around the traditional problem of node
inheritance: that including classes in any inherited node requires adding extra
helper classes just to enable value overrides.

On Mar 21, 2011, at 11:28 AM, Ashley Gould wrote:
> On Mon, Mar 21, 2011 at 04:23:40AM -0700, Bill Proud wrote:
>> The following would work:
>> 
>> node default {
>>    class { sudoers: }
>> }
>> 
>> node ''sl11lab02'' {
>>    class { sudoers: additional_rules => [ "$rules_uas" ] }
>> }
>> 
> 
> This does work, but I lose inheritance from node default.
> In fact, this is my current work around.
> 
> 
> -- 
> 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.
> 
-- 
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.

jcbollinger

2011-Mar-21 20:27 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

On Mar 21, 1:40 pm, jcbollinger <John.Bollin...@stJude.org>
wrote:> On Mar 21, 12:20 pm, hai wu <haiwu...@gmail.com> wrote:
>
> > I am going to use parameterized class together with extlookup, where
> > extlookup is used to provide different parameter value for different
node
> > based on extlookup_precedence, the parameterized class needs to be
declared
> > once in parent node, any issues you could forsee with this plan?
>
> I think the problems are few for which parameterized classes are the
> *best* solution.  Nevertheless the combination of parameterized
> classes with extlookup() may be the *most expedient* solution
> available at the moment.  It will very likely solve your problem.
Nevertheless, the way *I* would apply extlookup to the problem would
be more like this:

node default {
    class { sudoers: }
}

# No additional node definition needed for this purpose

class sudoers { # Not parameterized

    # This class should know how to choose
    # the default rule set for itself
    case $operatingsystem {
        "CentOS", "Debian", "Ubuntu",
"Solaris":
            { $default_rules = $rules_unixgroup }
        default:
            { $default_rules = $rules_other }
    }

    # If you''re using extlookup to get this, then
    # it''s better to do it right here
    $additional_rules = extlookup("additional_sudo_rules")

    file { "/tmp/sudoers":
        owner   => root,
        group => root,
        mode => 440,
        content => template("sudoers/sudoers.erb"),
        notify  => Exec["check-sudoers"],
    }

    exec { "check-sudoers":
        command => "/usr/sbin/visudo -cf /tmp/sudoers && cp
/tmp/
sudoers /etc/sudoers",
        refreshonly => true,
    }
}


Cheers,

John

-- 
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.

jcbollinger

2011-Mar-21 20:39 UTC

head link

[Puppet Users] Re: parameterized classes and variable inheritance

On Mar 21, 3:15 pm, Brian Gallew <g...@gallew.org>
wrote:> It has occurred to me that another way of doing this would be to use
defines
>
>   define kludge($sudo_add_rule=undef) {
>     node { "${name}":
>         class {sudoers: additional_rules => [$sudo_add_rule}}
>      }  
>   }
>
> The beauty of this is that it gets around the traditional problem of node
inheritance: that including classes in any inherited node requires adding extra
helper classes just to enable value overrides.
Does it actually work to declare a node inside a define?  I wouldn''t
have expected so, but if it does then that might prove useful to know.


John

-- 
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.

Brian Gallew

2011-Mar-21 21:23 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

On Mar 21, 2011, at 1:39 PM, jcbollinger wrote:
> 
> On Mar 21, 3:15 pm, Brian Gallew <g...@gallew.org> wrote:
>> It has occurred to me that another way of doing this would be to use
defines
>> 
>>   define kludge($sudo_add_rule=undef) {
>>     node { "${name}":
>>         class {sudoers: additional_rules => [$sudo_add_rule}}
>>      }  
>>   }
>> 
>> The beauty of this is that it gets around the traditional problem of
node inheritance: that including classes in any inherited node requires adding
extra helper classes just to enable value overrides.
> 
> Does it actually work to declare a node inside a define?  I
wouldn''t
> have expected so, but if it does then that might prove useful to know.
That will teach me to jump in before testing: no, it doesn''t work.

There goes another bright idea.

-- 
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.

Felix Frank

2011-Mar-22 08:44 UTC

head link

Re: [Puppet Users] parameterized classes and variable inheritance

> node default {
>     class { sudoers: }
> }
> 
> node ''sl11lab02'' inherits default {
> 
>     # this runs but does nothing
>     Class[sudoers] { additional_rules => [ "$rules_uas" ] }
> 
>     # this errors with "Cannot assign to variables in other
namespaces"
>     #$sudoers::additional_rules = [ "$rules_uas" ]
> 
>     # this errors with "Class[Sudoers] is already defined"
>     #class { sudoers: additional_rules => [ "$rules_uas" ] }
> }
> 
> class sudoers (
>     $default_rules    = "$rules_unixgroup",
>     $additional_rules = [ "" ]
>     ) {
> 
>     file { "/tmp/sudoers":
>         owner   => root, group => root, mode => 440,
>         content => template("sudoers/sudoers.erb"),
>         notify  => Exec["check-sudoers"],
>     }
> 
>     exec { "check-sudoers":
>         command => "/usr/sbin/visudo -cf /tmp/sudoers && cp
/tmp/sudoers /etc/sudoers",
>         refreshonly => true,
>     }
> 
> }
Hi,

is it me, or is class sudoers not actually parameterized?

What I''m seeing is a good old class with local variables. The way they
are initialized, they cannot even be overridden by (ab-)using dynamic
scoping, although this would probably work (plusignment):

include sudoers
$sudoers::additional_rules += [ a, b, c ]

To me, this actually does call for a (parameterized?) subclass that will
override the content of your /tmp file:

class sudoers_additional($additional_rules) inherits sudoers {
  File["..."] { content => template(...) }
}

This may even use the same template as the baseclass.

Don''t just hate subclasses. They''re often pretty helpful ;-)

HTH,
Felix

-- 
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.

Felix Frank

2011-Mar-22 08:53 UTC

head link

Re: [Puppet Users] parameterized classes and variable inheritance

> Hi,
> 
> is it me, or is class sudoers not actually parameterized?
Gah! It *is* me and my sort of ambiguous font. Never mind that bit then:
> What I''m seeing is a good old class with local variables. The way
they
> are initialized, they cannot even be overridden by (ab-)using dynamic
> scoping, although this would probably work (plusignment):
> 
> include sudoers
> $sudoers::additional_rules += [ a, b, c ]
The stuff about using subclasses holds true enough though ;-)

Sorry for the noise.

Felix

-- 
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.

Ashley Gould

2011-Mar-22 21:10 UTC

head link

Re: [Puppet Users] Re: parameterized classes and variable inheritance

On Mon, Mar 21, 2011 at 01:05:56PM -0700, jcbollinger
wrote:> 
> On Mar 21, 1:20 pm, Ashley Gould <ago...@ucop.edu> wrote:
> > Please forgive my ignorance.  I find myself, a linux admin brought
> > up on howtos and books with animals on the cover, suddenly plunged
> > by puppet into a world of developers and computer scientists.  Could
> > you explain what is "idempotency" and "support for
multiple inclusion"?
> 
> Sorry, my bad.  The point is that you can include an ordinary class
> multiple times on the same node (multiple inclusion), and the result
> is exactly the same as if that class were included only once
> (idempotency).  This can be important in a deep node inheritance
> hierarchy, but it is more commonly important in situations where
> classes include other classes.
> 
> For example, a common Puppet idiom is to create a "user" module
> containing a "user::virtual" class in which virtual user
resources are
> declared for all system users.  Other classes then make decisions
> about which users should actually be present on the system by
> realizing subsets of those users (via Puppet''s "realize"
function or
> <| |> syntax).  In my case, users are assigned to various research
> groups, so I have a class for each group that realizes the users
> associated with that group.  But those classes can only work if the
> user::virtual class is included in the node''s catalog.  It would
be
> possible to address that problem by ensuring that each node explicitly
> includes "user::virtual", but that''s clunky and subject
to breakage.
> Instead, it''s better for each class that wants to realize users to
> *itself* include user::virtual, which is possible and completely safe
> provided that user::virtual is not parameterized.
> 
> Parameterized classes, on the other hand, can be included only once
> per node, no matter what.  This is a substantial limitation on where
> and how such classes can be used.
> 
> I hope that helps.
> 
This helps bigtime.  Thanks to all for the wonderful comments on this
thread.  I am much more clear on a lot of things.

I have (for now) solved my issue by using a combination of regular and
param classes and scraping the node inheritance:

class sudoers {

    import "rules.pp"

    define make_sudoers($default_rules, $extra_rules) {

        file { "/tmp/sudoers":
            owner   => root, group => root, mode => 440,
            content => template("sudoers/sudoers.erb"),
            notify  => Exec["check-sudoers"],
        }
        exec { "check-sudoers":
            command => "/usr/sbin/visudo -cf /tmp/sudoers && \
                        cp /tmp/sudoers /etc/sudoers",
            refreshonly => true,
        }
    }

    make_sudoers {"default":
        default_rules    => "$rules_unixgroup",
        extra_rules => [ "" ],
    }

}


class sudoers_extras($rules) inherits sudoers {
    Sudoers::Make_sudoers[''default''] { extra_rules =>
$rules }
}


class common {
    include "sudoers"
}


node ''sl11lab02-vhost.ucop.edu'' {
    include "common"
    class { sudoers_extras: rules => [ "$rules_aig" ] }
}


-- 
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.

Puppet users - Mar 2011 - parameterized classes and variable inheritance

[Puppet Users] parameterized classes and variable inheritance

Re: [Puppet Users] parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

[Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance

Re: [Puppet Users] parameterized classes and variable inheritance

Re: [Puppet Users] parameterized classes and variable inheritance

Re: [Puppet Users] Re: parameterized classes and variable inheritance