thr3ads.net - Puppet users - [Puppet Users] Class inheritance [Nov 2010]

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

Chris C

2010-Nov-23 20:22 UTC

[Puppet Users] Class inheritance

Hello,
I''m trying to establish a simple inheritance

all_hosts > all_redhat  > DNS Master
                                       DNS Slaves
                                       Oracle RAC Nodes
                                       Web Nodes

all_hosts > all_solaris   > Web Nodes
                                       Jboss Nodes

I have classes with defined files and services for each class of
systems.

Here is an example...
cat classes/all/class.pp
    class all_hosts {
	file { "/etc/motd":
		ensure   => present,
		mode     => 644,
		owner    => root,
		group    => root,
		checksum => md5,
		source   =>
"/net/puppetmaster/etc/puppet/manifests/files/all/motd"
	}

cat classes/redhat/all/class.pp
    class all_linux {
	file { "/etc/motd":
		ensure   => present,
		mode     => 644,
		owner    => root,
		group    => root,
		checksum => md5,
		source   =>
"/net/puppetmaster/etc/puppet/manifests/files/all/motd"
	}

cat site.pp
    class all_hosts_redhat {
    #######################################################
    # CLASS DEFINITION
    import "classes/all/class.pp"
    import "classes/redhat/all/class.pp"
    #######################################################
    # NODE DEFINITIONS
    node default {
	include all_hosts

	}

    node /^prac6.akc.org/ {
	include all_linux

	}


I had a heck of a time getting around the "Duplicate Definition"
issue.

Shouldn''t file { "/etc/motd" in prac override file {
"/etc/motd" in
all_hosts?   When I do a puppetd --test the content of motd flip flops
between the two classes.

Maybe there is a better way to do this and I''m just missing something.

Thanks for the help!
/Chris C

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

2010-Nov-24 15:11 UTC

head link

[Puppet Users] Re: Class inheritance

On Nov 23, 2:22 pm, Chris C <mazzy...@gmail.com>
wrote:> I''m trying to establish a simple inheritance
Although people new to Puppet seem to like to try that, especially
when they have a programming background, it''s usually not a very good
idea.  For one thing, inheritance in Puppet doesn''t work the way
newbies typically expect it to do.  For another, it is frequently the
case that real-world systems don''t fit neatly into the cubbyhole of a
single leaf node of the tree.

[...]
> I have classes with defined files and services for each class of
> systems.
>
> Here is an example...
> cat classes/all/class.pp
>     class all_hosts {
>         file { "/etc/motd":
>                 ensure   => present,
>                 mode     => 644,
>                 owner    => root,
>                 group    => root,
>                 checksum => md5,
>                 source   =>
"/net/puppetmaster/etc/puppet/manifests/files/all/motd"
>         }
>
> cat classes/redhat/all/class.pp
>     class all_linux {
>         file { "/etc/motd":
>                 ensure   => present,
>                 mode     => 644,
>                 owner    => root,
>                 group    => root,
>                 checksum => md5,
>                 source   =>
"/net/puppetmaster/etc/puppet/manifests/files/all/motd"
>         }
>
> cat site.pp
>     class all_hosts_redhat {
>     #######################################################
>     # CLASS DEFINITION
>     import "classes/all/class.pp"
>     import "classes/redhat/all/class.pp"
>     #######################################################
>     # NODE DEFINITIONS
>     node default {
>         include all_hosts
>
>         }
>
>     node /^prac6.akc.org/ {
>         include all_linux
>
>         }
>
> I had a heck of a time getting around the "Duplicate Definition"
> issue.
>
> Shouldn''t file { "/etc/motd" in prac override file {
"/etc/motd" in
> all_hosts?
No.  For good reasons, Puppet forbids duplicate resource declarations
in the scope of any node (but see below).
>   When I do a puppetd --test the content of motd flip flops
> between the two classes.
That''s surprising, because

a) unless its hostname changes or your manifests change, each node
will get only one definition of File["/etc/motd"], and besides,
b) both definitions you have shown point to the same file. (*)

(*) Filesystem paths are resolved on the client, and it looks like in
your case the file is remote, so you might be getting changes either
because a different remote filesystem is mounted at different times or
because the remote file is changing.

> Maybe there is a better way to do this and I''m just missing
something.
Yes, there are better ways.  Here are several recommendations, with
varying degrees of specificity for your stated problem:

1) Organize your manifests into modules.  It is never too early to do
this.

2) As a general rule, do not declare resources directly in node
definitions.  Declare them only in classes or definitions.  (This does
not appear currently to be an issue for you.)

3) Where you want Puppet to manage individual files (such as /etc/
motd), use its built-in file server.  Refer clients to this by using a
"source" URL of the form
"puppet:///<module>/<file>".

4) If you don''t need or want a stand-alone external file to serve,
especially if the contents rarely change, then consider using
"content" instead of "source".

5) If you use node inheritance at all, keep your inheritance tree
extremely shallow.  If find yourself using more than two levels then
either refactor your manifests or switch to an external node
classifier (or both).

6) Instead of multiple, similar classes for differing circumstances,
write single classes that use nodes'' facts where necessary to tailor
resources to the target node.

7) Use classes instead of node groups to describe facilities or roles
that systems should have.  Nodes that serve multiple roles or have
multiple unrelated features then simply include all the appropriate
classes.

8) If you have resources so general that it''s otherwise difficult to
declare them in only one place, then create central, virtual
declarations for them, and "realize" them wherever needed.  System
users are the canonical example of such resources.

9) Puppet does provide a feature for overriding resource definitions:
a subclass may override properties of resources declared by one of its
superclasses, using a special syntax.  Leveraging this feature is the
*only* good reason for creating a subclass; for any other purpose it
is better to "include" another class than to inherit from it.  Avoid
the temptation to overuse resource overrides, however.

10) For details on how to use any of the features I''ve mentioned
above, consult the Puppet documentation.  In particular, these
documents may be helpful to you:
http://docs.puppetlabs.com/guides/language_tutorial.html,
http://docs.puppetlabs.com/guides/modules.html,
http://docs.puppetlabs.com/guides/file_serving.html.  Perhaps also
http://docs.puppetlabs.com/guides/best_practices.html, though it''s a
bit skeletal at the moment.

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.

Chris C

2010-Nov-24 15:37 UTC

head link

Re: [Puppet Users] Re: Class inheritance

Thanks for the reply!

I was able to get override to work correctly.
My classes are inheriting each other.  prac inherits all_hosts_redhat which
inherits all_hosts.
I cleaned up some unnecessary duplicate checks like chmod and own.
I changed the definition to the overided file to
File[''/etc/motd''] { ....
I also set a variable at the top of the class so I can easily override
content source
ie...
class all_hosts_redhat inherits all_hosts {

    $dir = redhat/all

    #CONFIGURE MOTD
    file { "/etc/motd":
        checksum => md5,
        source   =>
"/net/puppetmaster/etc/puppet/manifests/files/$dir/motd"
        }

}

This gives me the option to have different motd''s for different classes
and
I no longer have the funny flip flopping of content in motd...

The tutorial at puppetlabs really helped to iron out the issues.

I have some comments.  They are inline.
>
> > I had a heck of a time getting around the "Duplicate
Definition"
> > issue.
> >
> > Shouldn''t file { "/etc/motd" in prac override file
{ "/etc/motd" in
> > all_hosts?
>
> No.  For good reasons, Puppet forbids duplicate resource declarations
> in the scope of any node (but see below).
>
> >   When I do a puppetd --test the content of motd flip flops
> > between the two classes.
>
> That''s surprising, because
>
> a) unless its hostname changes or your manifests change, each node
> will get only one definition of File["/etc/motd"], and besides,
> b) both definitions you have shown point to the same file. (*)
>
> (*) Filesystem paths are resolved on the client, and it looks like in
> your case the file is remote, so you might be getting changes either
> because a different remote filesystem is mounted at different times or
> because the remote file is changing.
>
>Maybe I found a bug.  Does Puppetlabs pay like Mozilla pays?  ;)


>
> > Maybe there is a better way to do this and I''m just missing
something.
>
> Yes, there are better ways.  Here are several recommendations, with
> varying degrees of specificity for your stated problem:
>
> 1) Organize your manifests into modules.  It is never too early to do
> this.
>
>What do you mean by this?  I thought my manifest was modular?


> 2) As a general rule, do not declare resources directly in node
> definitions.  Declare them only in classes or definitions.  (This does
> not appear currently to be an issue for you.)
>
>Only class includes are being added to my node definition


> 3) Where you want Puppet to manage individual files (such as /etc/
> motd), use its built-in file server.  Refer clients to this by using a
> "source" URL of the form
"puppet:///<module>/<file>".
>
>Is using the puppet fileserver high performance?  I''m expecting to have
300-500 clients.  These VM''s just keep popping up like daisy''s
in my lawn.


4) If you don''t need or want a stand-alone external file to
serve,> especially if the contents rarely change, then consider using
> "content" instead of "source".
>
>Hm.  I think I will consider that.  I have 60 some checks and doing
md5sum''s
seems heavy weight.

My intention is to use Puppet to manage the content of our public website.
Our website is extensive.


> 5) If you use node inheritance at all, keep your inheritance tree
> extremely shallow.  If find yourself using more than two levels then
> either refactor your manifests or switch to an external node
> classifier (or both).
>
>I do want to use an external node classifier.  I don''t think
I''m far enough
along yet.

I would like our Active Directory to hold manifest data.  Unfortunately our
AD needs ALOT of cowbell at this time.  That is going to be my winter
project.


> 6) Instead of multiple, similar classes for differing circumstances,
> write single classes that use nodes'' facts where necessary to
tailor
> resources to the target node.
>
> 7) Use classes instead of node groups to describe facilities or roles
> that systems should have.  Nodes that serve multiple roles or have
> multiple unrelated features then simply include all the appropriate
> classes.
>
> 8) If you have resources so general that it''s otherwise difficult
to
> declare them in only one place, then create central, virtual
> declarations for them, and "realize" them wherever needed. 
System
> users are the canonical example of such resources.
>
>I saw those features in the tutorial.  I''m definitely going to go that
direction.  I''m glad to get this first step to work.

My classes are already getting out of hand.  It sure didn''t take long.


> 9) Puppet does provide a feature for overriding resource definitions:
> a subclass may override properties of resources declared by one of its
> superclasses, using a special syntax.  Leveraging this feature is the
> *only* good reason for creating a subclass; for any other purpose it
> is better to "include" another class than to inherit from it. 
Avoid
> the temptation to overuse resource overrides, however.
>
> 10) For details on how to use any of the features I''ve mentioned
> above, consult the Puppet documentation.  In particular, these
> documents may be helpful to you:
> http://docs.puppetlabs.com/guides/language_tutorial.html,
> http://docs.puppetlabs.com/guides/modules.html,
> http://docs.puppetlabs.com/guides/file_serving.html.  Perhaps also
> http://docs.puppetlabs.com/guides/best_practices.html, though it''s
a
> bit skeletal at the moment.
>
>
Thanks,
/Chris C

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

2010-Nov-29 14:46 UTC

head link

[Puppet Users] Re: Class inheritance

On Nov 24, 9:37 am, Chris C <mazzy...@gmail.com>
wrote:> I was able to get override to work correctly.
I''m glad to hear it.
> My classes are inheriting each other.  prac inherits all_hosts_redhat which
> inherits all_hosts.
> I cleaned up some unnecessary duplicate checks like chmod and own.
> I changed the definition to the overided file to
File[''/etc/motd''] { ....
> I also set a variable at the top of the class so I can easily override
> content source
A class defining the common elements for all managed systems seems a
relatively common practice.  It works for many people, but the devil
is in the details.

[...]
> > >   When I do a puppetd --test the content of motd flip flops
> > > between the two classes.
>
> > That''s surprising, because
>
> > a) unless its hostname changes or your manifests change, each node
> > will get only one definition of File["/etc/motd"], and
besides,
> > b) both definitions you have shown point to the same file. (*)
>
> > (*) Filesystem paths are resolved on the client, and it looks like in
> > your case the file is remote, so you might be getting changes either
> > because a different remote filesystem is mounted at different times or
> > because the remote file is changing.
>
> Maybe I found a bug.  Does Puppetlabs pay like Mozilla pays?  ;)
Not like Mozilla pays, no.  Puppetlabs pays for accepted bug reports
by giving you the fixed version, when it''s ready, free of charge.  In
fact, you could consider filing good bug reports to be a quid pro quo
for Puppetlabs having given you Puppet in the first place.
> > 1) Organize your manifests into modules.  It is never too early to do
> > this.
>
> What do you mean by this?  I thought my manifest was modular?
I mean "module" in its Puppet-specific sense.  See
http://docs.puppetlabs.com/guides/modules.html.
> > 3) Where you want Puppet to manage individual files (such as /etc/
> > motd), use its built-in file server.  Refer clients to this by using a
> > "source" URL of the form
"puppet:///<module>/<file>".
>
> Is using the puppet fileserver high performance?  I''m expecting to
have
> 300-500 clients.  These VM''s just keep popping up like
daisy''s in my lawn.
If you anticipate that many clients then you should be running Puppet
itself behind Apache httpd, via Passenger.

Whether Puppet''s file serving performance suffices depends on many
parameters, some of them external to Puppet itself.  I think the file
server''s inherent efficiency is reasonably good, but you should be
aware that however files are served, Puppet uses checksumming (MD5 by
default) when managing them to determine which need to be synced.  You
can instruct Puppet to use modification time instead, which will
greatly speed it up at the cost of reducing its reliability for
detecting out-of-sync files.
> My intention is to use Puppet to manage the content of our public website.
> Our website is extensive.
Honestly, I don''t think that''s a great idea.  Puppet will be
good for
managing the servers themselves, but not so much for directly managing
their extensive web content.  Have you considered instead using a
version control system, such as Subversion or git?  Puppet can easily
manage a cron job to periodically pull down changes, or you could use
an exec to have Puppet pull down changes itself on every run.  Among
the advantages of doing it this way:

a) easy reversion of errors

b) content changes are traceable to specific users

c) web developers don''t interact with Puppet


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.

Nigel Kersten

2010-Nov-29 14:57 UTC

head link

Re: [Puppet Users] Re: Class inheritance

On Mon, Nov 29, 2010 at 6:46 AM, jcbollinger <John.Bollinger@stjude.org>
wrote:>
>
> On Nov 24, 9:37 am, Chris C <mazzy...@gmail.com> wrote:
>> I was able to get override to work correctly.
>
> I''m glad to hear it.
>
>> My classes are inheriting each other.  prac inherits all_hosts_redhat
which
>> inherits all_hosts.
>> I cleaned up some unnecessary duplicate checks like chmod and own.
>> I changed the definition to the overided file to
File[''/etc/motd''] { ....
>> I also set a variable at the top of the class so I can easily override
>> content source
>
> A class defining the common elements for all managed systems seems a
> relatively common practice.  It works for many people, but the devil
> is in the details.
>
> [...]
>
>> > >   When I do a puppetd --test the content of motd flip flops
>> > > between the two classes.
>>
>> > That''s surprising, because
>>
>> > a) unless its hostname changes or your manifests change, each node
>> > will get only one definition of File["/etc/motd"], and
besides,
>> > b) both definitions you have shown point to the same file. (*)
>>
>> > (*) Filesystem paths are resolved on the client, and it looks like
in
>> > your case the file is remote, so you might be getting changes
either
>> > because a different remote filesystem is mounted at different
times or
>> > because the remote file is changing.
>>
>> Maybe I found a bug.  Does Puppetlabs pay like Mozilla pays?  ;)
>
> Not like Mozilla pays, no.  Puppetlabs pays for accepted bug reports
> by giving you the fixed version, when it''s ready, free of charge.
 In
> fact, you could consider filing good bug reports to be a quid pro quo
> for Puppetlabs having given you Puppet in the first place.
>
>> > 1) Organize your manifests into modules.  It is never too early to
do
>> > this.
>>
>> What do you mean by this?  I thought my manifest was modular?
>
> I mean "module" in its Puppet-specific sense.  See
> http://docs.puppetlabs.com/guides/modules.html.
>
>> > 3) Where you want Puppet to manage individual files (such as /etc/
>> > motd), use its built-in file server.  Refer clients to this by
using a
>> > "source" URL of the form
"puppet:///<module>/<file>".
>>
>> Is using the puppet fileserver high performance?  I''m
expecting to have
>> 300-500 clients.  These VM''s just keep popping up like
daisy''s in my lawn.
>
> If you anticipate that many clients then you should be running Puppet
> itself behind Apache httpd, via Passenger.
>
> Whether Puppet''s file serving performance suffices depends on many
> parameters, some of them external to Puppet itself.  I think the file
> server''s inherent efficiency is reasonably good, but you should be
> aware that however files are served, Puppet uses checksumming (MD5 by
> default) when managing them to determine which need to be synced.  You
> can instruct Puppet to use modification time instead, which will
> greatly speed it up at the cost of reducing its reliability for
> detecting out-of-sync files.
>
>> My intention is to use Puppet to manage the content of our public
website.
>> Our website is extensive.
>
> Honestly, I don''t think that''s a great idea.  Puppet will
be good for
> managing the servers themselves, but not so much for directly managing
> their extensive web content.  Have you considered instead using a
> version control system, such as Subversion or git?  Puppet can easily
> manage a cron job to periodically pull down changes, or you could use
> an exec to have Puppet pull down changes itself on every run.  Among
> the advantages of doing it this way:
>
> a) easy reversion of errors
>
> b) content changes are traceable to specific users
>
> c) web developers don''t interact with Puppet
I often have trouble convincing people of this, but if you''ve got a
good automated package build environment, I''m a big fan of packaging
content like websites based upon tags, and then using Puppet to ensure
those packages are installed.

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


-- 
Nigel Kersten - Puppet Labs -  http://www.puppetlabs.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-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 - Nov 2010 - Class inheritance

[Puppet Users] Class inheritance

[Puppet Users] Re: Class inheritance

Re: [Puppet Users] Re: Class inheritance

[Puppet Users] Re: Class inheritance

Re: [Puppet Users] Re: Class inheritance