Ok, I''ve been reading and I have some questions about best practices:
I understand that modules are to be self contained blocks that i can
just drop in. Using best practices, how does this fit into the naming
scheme?
Classes are singletons. I think i understand this. I''ve been
defining classes in /etc/puppet/classes, but then how does this relate
to any modules i might want to use?
what is the difference between
class::whateverthismethodlikethingisinpuppetsyntax and class? ie:
class apache {
#
}
class apache::wtf {
#
}
What is the actual function of site.pp? I had thought it was the
entry point for puppetmasterd. so how would I include a module in a
site?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Anyone else feel free to step in and correct me, but here''s how I see it... 2008/11/24 kevin <lazyweb@gmail.com>> > Ok, I''ve been reading and I have some questions about best practices: > > I understand that modules are to be self contained blocks that i can > just drop in. Using best practices, how does this fit into the naming > scheme? > > Classes are singletons. I think i understand this. I''ve been > defining classes in /etc/puppet/classes, but then how does this relate > to any modules i might want to use? >So, the idea behind a module really relates more to organization than anything else. Generally speaking, modules contain classes. But back to your question. The fact you''re defining classes in /etc/puppet/classes only relates to any modules you might want to use if you define a class that has the same name as a class defined in a module, inwhich case you''d have a naming conflict.> what is the difference between > class::whateverthismethodlikethingisinpuppetsyntax and class? ie: > > class apache { > # > } > > class apache::wtf { > # > } >Effectively everything. ''class'' vs ''class:foo'' are two different classes. The idea is ''class::foo'' is a subclass of ''class'', however there isn''t anything besides sanity that enforces this. if you wanted class ''apache::wtf'' to setup NIS+ and class ''apache'' sets up a TFTP server, then that''s your deal. Generally speaking you''d set that relationship up to be subclassed like the below contrived example: class apache { package { ''apache'': ensure => ''installed'', } service { ''apache'': ensure => ''running'', } file { "/etc/apache/httpd.conf": source => ''puppet:///apache/normal.conf'', } } class apache::wtf inherits apache { File["/etc/apache/httpd.conf"] { source => ''puppet:///apache/wtf.conf'', } } Some syntax might be wrong, its monday and a short week in the states so I''m a bit checked out. In any event you''d have a node that includes ''apache:wtf'', which inherits ''apache'' so you get all the work you did in that class as well, with the override of httpd.conf also, classes are not methods...> > What is the actual function of site.pp? I had thought it was the > entry point for puppetmasterd. so how would I include a module in a > site? > > site.pp is included whenever a client requests a configuration. Generallyspeaking you''d have your node definitions in there (or in nodes.pp, or in an external node tool). I also use it to set defaults for types, eg setting a path for Exec, setting ensure => installed for Package, etc (but I''m also very lazy). As for including a module from site.pp, you''d just say ''include mymodule''. This does require some plumbing: in your puppet.conf under the [puppetmaster] section add something like[1]: modulepath = /var/lib/puppet/modules Then just copy the module to that directory. For example if you had the module ''foo'' you would end up with something like: /var/lib/puppet/modules/foo/manifests/init.pp /var/lib/puppet/modules/foo/manifests/subclass.pp /var/lib/puppet/modules/foo/files/myfile.txt /var/lib/puppet/modules/foo/files/otherfile.txt /var/lib/puppet/modules/foo/templates/example.erb Puppet will ''magically'' take care of .r'' [1]: http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation --~--~---------~--~----~------------~-------~--~----~ 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 Nov 24, 1:37 pm, RijilV <rij...@riji.lv> wrote:> Anyone else feel free to step in and correct me, but here''s how I see it... > > 2008/11/24 kevin <lazy...@gmail.com> > > > > > Ok, I''ve been reading and I have some questions about best practices: > > > I understand that modules are to be self contained blocks that i can > > just drop in. Using best practices, how does this fit into the naming > > scheme? > > > Classes are singletons. I think i understand this. I''ve been > > defining classes in /etc/puppet/classes, but then how does this relate > > to any modules i might want to use? > > So, the idea behind a module really relates more to organization than > anything else. Generally speaking, modules contain classes. But back to > your question. The fact you''re defining classes in /etc/puppet/classes only > relates to any modules you might want to use if you define a class that has > the same name as a class defined in a module, inwhich case you''d have a > naming conflict. > > > what is the difference between > > class::whateverthismethodlikethingisinpuppetsyntax and class? ie: > > > class apache { > > # > > } > > > class apache::wtf { > > # > > } > > Effectively everything. ''class'' vs ''class:foo'' are two different classes. > The idea is ''class::foo'' is a subclass of ''class'', however there isn''t > anything besides sanity that enforces this. if you wanted class > ''apache::wtf'' to setup NIS+ and class ''apache'' sets up a TFTP server, then > that''s your deal. Generally speaking you''d set that relationship up to be > subclassed like the below contrived example: > > class apache { > package { ''apache'': > ensure => ''installed'', > } > > service { ''apache'': > ensure => ''running'', > } > > file { "/etc/apache/httpd.conf": > source => ''puppet:///apache/normal.conf'', > } > > } > > class apache::wtf inherits apache { > File["/etc/apache/httpd.conf"] { > source => ''puppet:///apache/wtf.conf'', > } > > } > > Some syntax might be wrong, its monday and a short week in the states so I''m > a bit checked out. In any event you''d have a node that includes > ''apache:wtf'', which inherits ''apache'' so you get all the work you did in > that class as well, with the override of httpd.conf > > also, classes are not methods... > > > > > What is the actual function of site.pp? I had thought it was the > > entry point for puppetmasterd. so how would I include a module in a > > site? > > > site.pp is included whenever a client requests a configuration. Generally > > speaking you''d have your node definitions in there (or in nodes.pp, or in an > external node tool). I also use it to set defaults for types, eg setting a > path for Exec, setting ensure => installed for Package, etc (but I''m also > very lazy). > > As for including a module from site.pp, you''d just say ''include mymodule''. > This does require some plumbing: in your puppet.conf under the > [puppetmaster] section add something like[1]: > > modulepath = /var/lib/puppet/modules > > Then just copy the module to that directory. For example if you had the > module ''foo'' you would end up with something like: > > /var/lib/puppet/modules/foo/manifests/init.pp > /var/lib/puppet/modules/foo/manifests/subclass.pp > /var/lib/puppet/modules/foo/files/myfile.txt > /var/lib/puppet/modules/foo/files/otherfile.txt > /var/lib/puppet/modules/foo/templates/example.erb > > Puppet will ''magically'' take care of > > .r'' > > [1]:http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisationThanks a lot, This really helps. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---