Hello everyone, My team and I have been mulling over the module standards that were proposed (http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards) Members of our team like to break large classes up into tiny pieces, which isn''t covered in this doc. For instance, if a class declares 10 files and 12 packages and 5 services, there is a preference to break these into foo::files, foo::packages, and foo:services and then have foo include these things. My problem with this is that I like to preserve a clear representation that :: denotes that the thing following is a subclass of the thing proceeding (so ssh::server means this is a subclass of ssh, relating specifically to ssh). So my proposal is if there is need or want to break up large classes, the fragment class (i.e. foo::files) be named specifically in a way that makes it clear it is not a complete and functional class but only a fragment. Such a naming convention might call for something like foo::_files or foo::inc::files. I would like to open this topic up to discussion to the greater community (you guys) and see what you think. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2008/9/16 Digant C Kasundra <digant@stanford.edu>:> > Hello everyone, > > My team and I have been mulling over the module standards that were proposed (http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards) > > Members of our team like to break large classes up into tiny pieces, which isn''t covered in this doc. For instance, if a class declares 10 files and 12 packages and 5 services, there is a preference to break these into foo::files, foo::packages, and foo:services and then have foo include these things. My problem with this is that I like to preserve a clear representation that :: denotes that the thing following is a subclass of the thing proceeding (so ssh::server means this is a subclass of ssh, relating specifically to ssh). > > So my proposal is if there is need or want to break up large classes, the fragment class (i.e. foo::files) be named specifically in a way that makes it clear it is not a complete and functional class but only a fragment. Such a naming convention might call for something like foo::_files or foo::inc::files. I would like to open this topic up to discussion to the greater community (you guys) and see what you think. >I guess I could see this if the classes were scattered throughout /manifests/. I approach module building the same way in terms of breaking the classes into smaller pieces. I guess I don''t see a specific need for a fragment designation. I usually create a class named "foo" in init.pp and include the sub classes there: class files { # include files class groups include files::all include files::rhel5 # include files class hosts include files::host1 } In site.pp I just "include foo." I document all this in the README and comment the init.pp file. It just seems natural to me that way. My setup isn''t probably as complex as some so maybe I''m missing something...... Kent --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
When things are fairly small, it isn''t an issue and certainly documentation is key. I''m just very OCD about conventions and naming and I like having things named in ways that it is explicit to the purpose. Generally, it is fairly easy to tell that ssh::files would most likely be a class that deals with the files associated with setting up ssh and not some variation of how ssh is setup. But, in general, when I see foo::bar, I assume bar is a subclass (ergo derivative of) foo. But since both fragments and subclasses are useful in Puppet, for those that so feel inclined (and I think the Puppet community has expressed interest in consistent style and practice guides to grow the community closer), I think a naming convention to differentiate is valuable, even if just for us OCD folks. :) ----- Original Message ----- From: "Kenton Brede" <kbrede@gmail.com> To: puppet-users@googlegroups.com Sent: Tuesday, September 16, 2008 12:40:09 PM GMT -08:00 US/Canada Pacific Subject: [Puppet Users] Re: Module Standards 2008/9/16 Digant C Kasundra <digant@stanford.edu>:> So my proposal is if there is need or want to break up large classes, the fragment class (i.e. foo::files) be named specifically in a way that makes it clear it is not a complete and functional class but only a fragment. Such a naming convention might call for something like foo::_files or foo::inc::files. I would like to open this topic up to discussion to the greater community (you guys) and see what you think. >I guess I could see this if the classes were scattered throughout /manifests/. I approach module building the same way in terms of breaking the classes into smaller pieces. I guess I don''t see a specific need for a fragment designation. I usually create a class named "foo" in init.pp and include the sub classes there: class files { # include files class groups include files::all include files::rhel5 # include files class hosts include files::host1 } In site.pp I just "include foo." I document all this in the README and comment the init.pp file. It just seems natural to me that way. My setup isn''t probably as complex as some so maybe I''m missing something...... Kent -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I vote for foo::_files. Kent 2008/9/22 Digant C Kasundra <digant@stanford.edu>:> > When things are fairly small, it isn''t an issue and certainly documentation is key. I''m just very OCD about conventions and naming and I like having things named in ways that it is explicit to the purpose. Generally, it is fairly easy to tell that ssh::files would most likely be a class that deals with the files associated with setting up ssh and not some variation of how ssh is setup. But, in general, when I see foo::bar, I assume bar is a subclass (ergo derivative of) foo. But since both fragments and subclasses are useful in Puppet, for those that so feel inclined (and I think the Puppet community has expressed interest in consistent style and practice guides to grow the community closer), I think a naming convention to differentiate is valuable, even if just for us OCD folks. :) > > > ----- Original Message ----- > From: "Kenton Brede" <kbrede@gmail.com> > To: puppet-users@googlegroups.com > Sent: Tuesday, September 16, 2008 12:40:09 PM GMT -08:00 US/Canada Pacific > Subject: [Puppet Users] Re: Module Standards > > > 2008/9/16 Digant C Kasundra <digant@stanford.edu>: > >> So my proposal is if there is need or want to break up large classes, the fragment class (i.e. foo::files) be named specifically in a way that makes it clear it is not a complete and functional class but only a fragment. Such a naming convention might call for something like foo::_files or foo::inc::files. I would like to open this topic up to discussion to the greater community (you guys) and see what you think. >> > > I guess I could see this if the classes were scattered throughout /manifests/. > I approach module building the same way in terms of breaking the classes > into smaller pieces. I guess I don''t see a specific need for a > fragment designation. > I usually create a class named "foo" in init.pp and include the sub > classes there: > > class files { > # include files class groups > include files::all > include files::rhel5 > # include files class hosts > include files::host1 > } > > In site.pp I just "include foo." I document all this in the README > and comment the init.pp file. It just seems natural to me that way. > My setup isn''t probably as complex as some so maybe I''m missing > something...... > Kent > > > > -- > Digant C Kasundra <digant@stanford.edu> > Technical Lead, ITS Unix Systems and Applications, Stanford University > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Except foo::_files is a "syntax error"...... Kent 2008/9/23 Kenton Brede <kbrede@gmail.com>:> I vote for foo::_files. > Kent > > 2008/9/22 Digant C Kasundra <digant@stanford.edu>: >> >> When things are fairly small, it isn''t an issue and certainly documentation is key. I''m just very OCD about conventions and naming and I like having things named in ways that it is explicit to the purpose. Generally, it is fairly easy to tell that ssh::files would most likely be a class that deals with the files associated with setting up ssh and not some variation of how ssh is setup. But, in general, when I see foo::bar, I assume bar is a subclass (ergo derivative of) foo. But since both fragments and subclasses are useful in Puppet, for those that so feel inclined (and I think the Puppet community has expressed interest in consistent style and practice guides to grow the community closer), I think a naming convention to differentiate is valuable, even if just for us OCD folks. :)>> >> >> ----- Original Message ----- >> From: "Kenton Brede" <kbrede@gmail.com> >> To: puppet-users@googlegroups.com >> Sent: Tuesday, September 16, 2008 12:40:09 PM GMT -08:00 US/Canada Pacific >> Subject: [Puppet Users] Re: Module Standards >> >> >> 2008/9/16 Digant C Kasundra <digant@stanford.edu>: >> >>> So my proposal is if there is need or want to break up large classes, the fragment class (i.e. foo::files) be named specifically in a way that makes it clear it is not a complete and functional class but only a fragment. Such a naming convention might call for something like foo::_files or foo::inc::files. I would like to open this topic up to discussion to the greater community (you guys) and see what you think. >>> >> >> I guess I could see this if the classes were scattered throughout /manifests/. >> I approach module building the same way in terms of breaking the classes >> into smaller pieces. I guess I don''t see a specific need for a >> fragment designation. >> I usually create a class named "foo" in init.pp and include the sub >> classes there: >> >> class files { >> # include files class groups >> include files::all >> include files::rhel5 >> # include files class hosts >> include files::host1 >> } >> >> In site.pp I just "include foo." I document all this in the README >> and comment the init.pp file. It just seems natural to me that way. >> My setup isn''t probably as complex as some so maybe I''m missing >> something...... >> Kent >> >> >> >> -- >> Digant C Kasundra <digant@stanford.edu> >> Technical Lead, ITS Unix Systems and Applications, Stanford University >> >> >> >> >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi Digant,
what''s the best place to comment/discuss what is written in:
http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards ?
I''d like to take part in the discussion about the module standards but
I don''t think the wiki is the right places to submit ideas/remarks.
So for the moment I write here.
For example I find point 5 in the Modules Standards section, a bit
over engineered and not well manageable in the log term:
I don''t find the necessity to introduce a new variable for every
package and service name (and pathname for almost each file served, so
in some cases you should define a lot of variables for a module).
I would handle the operating systems differences where is necessary
with a relevant switch, like here:
class sendmail {
package {
sendmail:
name => $operatingsystem ? {
default => "sendmail",
},
ensure => present;
sendmail-cf:
name => $operatingsystem ? {
default => "sendmail-cf",
},
ensure => present,
}
service { sendmail:
name => $operatingsystem ? {
default => "sendmail",
},
ensure => running,
enable => true,
hasrestart => true,
hasstatus => true,
require => Package[sendmail],
}
file {
"sendmail.cf":
mode => 644, owner => root, group => root,
require => Package[sendmail],
ensure => present,
path => $operatingsystem ?{
default => "/etc/mail/sendmail.cf",
},
}
}
In any case, this is just an example (and, in this case, a solution or
another I guess it''s mostly a matter of personal taste).
Another point quite critical, according to me, is the standardization
of modules that need to manage objects provided by other modules.
An example could be a module for a software like mailcanner or amavis
or whatever: they should handle configuration files and other objects
of different other programs (for example an MTA like postfix, mail
filters like spamassassin and clamav and so on).
How can this be handled in a modular standard way (the mantainer of
mailscanner module is not necessarily the postfix mantainer)?
I''ve thought about different scenarios but they all require some
tweaks that can be more or less acceptable (for example a conflict
with other modules).
Best regards,
al
--~--~---------~--~----~------------~-------~--~----~
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 Sep 16, 2008, at 12:16 PM, Digant C Kasundra wrote:> > Hello everyone, > > My team and I have been mulling over the module standards that were > proposed (http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards > ) > > Members of our team like to break large classes up into tiny pieces, > which isn''t covered in this doc. For instance, if a class declares > 10 files and 12 packages and 5 services, there is a preference to > break these into foo::files, foo::packages, and foo:services and > then have foo include these things. My problem with this is that I > like to preserve a clear representation that :: denotes that the > thing following is a subclass of the thing proceeding (so > ssh::server means this is a subclass of ssh, relating specifically > to ssh). > > So my proposal is if there is need or want to break up large > classes, the fragment class (i.e. foo::files) be named specifically > in a way that makes it clear it is not a complete and functional > class but only a fragment. Such a naming convention might call for > something like foo::_files or foo::inc::files. I would like to open > this topic up to discussion to the greater community (you guys) and > see what you think.Are your classes really getting that long? And does it really make sense to split them based on resource type, rather than some other organizational criteria? The cfengine community was often hampered by a tendency to organize by action type rather than functional role, so I consider it a kind of code smell in Puppet. -- Aizu''s Second Law: What changes the world is communication, not information. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.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 -~----------~----~----~----~------~----~------~--~---
2008/9/25 Luke Kanies <luke@madstop.com>:> > On Sep 16, 2008, at 12:16 PM, Digant C Kasundra wrote: > >> >> Hello everyone, >> >> My team and I have been mulling over the module standards that were >> proposed (http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards >> ) >> >> Members of our team like to break large classes up into tiny pieces, >> which isn''t covered in this doc. For instance, if a class declares >> 10 files and 12 packages and 5 services, there is a preference to >> break these into foo::files, foo::packages, and foo:services and >> then have foo include these things. My problem with this is that I >> like to preserve a clear representation that :: denotes that the >> thing following is a subclass of the thing proceeding (so >> ssh::server means this is a subclass of ssh, relating specifically >> to ssh). >> >> So my proposal is if there is need or want to break up large >> classes, the fragment class (i.e. foo::files) be named specifically >> in a way that makes it clear it is not a complete and functional >> class but only a fragment. Such a naming convention might call for >> something like foo::_files or foo::inc::files. I would like to open >> this topic up to discussion to the greater community (you guys) and >> see what you think. > > > Are your classes really getting that long? > > And does it really make sense to split them based on resource type, > rather than some other organizational criteria?I''d like to jump in here if I may. I''m in the process of reorganizing our manifest. One of the things I''m trying to do is make our manifest easy to understand, easy to use and easy to scale. I want to create something that will be used when I''m gone. What I''m doing at this point is moving from /etc/puppet/manifests/classes to /modules/. I have a "files" module/class that includes all.pp, rhel5.pp, host.pp, etc. Each of these subclasses are wrapped with a case statement so they are only applied to a group or single host. The "files" class includes the subclasses. Doing it this way, you end up with more classes. But I think that beats trawling through a huge files.pp, looking for the proper place to add a file or host, especially if you aren''t failure with the file. The way I look at it, this organization should allow someone to come in and think, "I have a file to manage, oh file module." Lets look at the manifest, "My file will only be applied to rhel5 boxes, oh lets look at rhel5.pp." The site.pp file doesn''t have to be touched because "include files" is in the base node. The README is in place for the class and current files have a "this file managed by Puppet class::foo" in place. Currently I have two types of modules, those based on a type (such as file, package) or those based on a service (such as apache, firewall). A cron job might end up in cron.pp, if it isn''t tied to another type. Or a cron job might end up in a service module as a subclass. My question is, what''s wrong with this setup? I ask this realizing the smallness of our operation makes me a little myopic.> The cfengine community was often hampered by a tendency to organize by > action type rather than functional role, so I consider it a kind of > code smell in Puppet.Could you give a couple examples of what you mean by "action type" and "functional role?" Thanks, Kent --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi, I noticed the Documentation link in the page header is broken on all trac
instances. Please fix this, it will save a few clicks.
http://reductivelabs.com/trac/puppet
The doc link for the main puppet instance should point here:
http://reductivelabs.com/trac/puppet/wiki/DocumentationStart
Thanks.
--~--~---------~--~----~------------~-------~--~----~
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 John Philips wrote:> Hi, I noticed the Documentation link in the page header is broken on all trac instances. Please fix this, it will save a few clicks. > > http://reductivelabs.com/trac/puppet > > The doc link for the main puppet instance should point here: http://reductivelabs.com/trac/puppet/wiki/DocumentationStart >The link does point there but something is going wrong. Andrew? Regards James Turnbull - -- Author of: * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3X109hTGvAxC30ARAtBtAJwNic/dgOCj7xrGAMYsFGrSNhN9cQCgrXNY rzNGgO2pe+2NoQa/HEV3m8M=Y8Z6 -----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 -~----------~----~----~----~------~----~------~--~---
James/Andrew, I viewed the page source and found a hint to the problem. <a href="http://reductivelabs.com/trac/puppet/wiki/GettingHelp" title="Support">Support</a></li><li id="docs"> <a class="selected" title ="Documentation">Documentation</a> The Support link is correct, the Documentation link uses the ''selected'' class but has no href. On another note, I see the Get Started link directs to a https URL and Firefox complains of an invalid certificate. Please change that to http so it''s unencrypted like the rest of the site. --- On Fri, 9/26/08, James Turnbull <james@lovedthanlost.net> wrote:> From: James Turnbull <james@lovedthanlost.net> > Subject: [Puppet Users] Re: Fix Documentation link on wiki > To: puppet-users@googlegroups.com > Date: Friday, September 26, 2008, 5:25 PM > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Philips wrote: > > Hi, I noticed the Documentation link in the page > header is broken on all trac instances. Please fix this, it > will save a few clicks. > > > > http://reductivelabs.com/trac/puppet > > > > The doc link for the main puppet instance should point > here: > http://reductivelabs.com/trac/puppet/wiki/DocumentationStart > > > > The link does point there but something is going wrong. > Andrew? > > Regards > > James Turnbull > > - -- > Author of: > * Pulling Strings with Puppet > (http://www.amazon.com/gp/product/1590599780/) > * Pro Nagios 2.0 > (http://www.amazon.com/gp/product/1590596099/) > * Hardening Linux > (http://www.amazon.com/gp/product/1590594444/) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org > > iD8DBQFI3X109hTGvAxC30ARAtBtAJwNic/dgOCj7xrGAMYsFGrSNhN9cQCgrXNY > rzNGgO2pe+2NoQa/HEV3m8M> =Y8Z6 > -----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 -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Philips wrote:> James/Andrew, > > I viewed the page source and found a hint to the problem. > > <a href="http://reductivelabs.com/trac/puppet/wiki/GettingHelp" title="Support">Support</a></li><li id="docs"> > <a class="selected" title ="Documentation">Documentation</a> > > The Support link is correct, the Documentation link uses the ''selected'' class but has no href.That''s a bit of JS used to highlight the current nav bar entry. If I look at the source on the box its got a href. I suspect Andrew will need to take a quick look.> On another note, I see the Get Started link directs to a https URL and Firefox complains of an invalid certificate. Please change that to http so it''s unencrypted like the rest of the site. >Ditto for this one. Regards James Turnbull - -- Author of: * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3h7C9hTGvAxC30ARAntQAJ4xY/LnwCtqJlfdWtfMMALqAAQXbACeJjwW KjpD2PD8agHIrNXn7eY+w+I=W0fV -----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 -~----------~----~----~----~------~----~------~--~---
----- "Al @ Lab42" <lab42.it@gmail.com> wrote:> Hi Digant, > what''s the best place to comment/discuss what is written in: > http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards ? > > I''d like to take part in the discussion about the module standards > but > I don''t think the wiki is the right places to submit ideas/remarks. > So for the moment I write here.I think this is the right place to discuss that.> > For example I find point 5 in the Modules Standards section, a bit > over engineered and not well manageable in the log term: > I don''t find the necessity to introduce a new variable for every > package and service name (and pathname for almost each file served, > so > in some cases you should define a lot of variables for a module). > I would handle the operating systems differences where is necessary > with a relevant switch, like here: > > class sendmail { > > package { > sendmail: > name => $operatingsystem ? { > default => "sendmail", > }, > ensure => present; > > sendmail-cf: > name => $operatingsystem ? { > default => "sendmail-cf", > }, > ensure => present, > } > > service { sendmail: > name => $operatingsystem ? { > default => "sendmail", > }, > ensure => running, > enable => true, > hasrestart => true, > hasstatus => true, > require => Package[sendmail], > } > > file { > "sendmail.cf": > mode => 644, owner => root, group => root, > require => Package[sendmail], > ensure => present, > path => $operatingsystem ?{ > default => "/etc/mail/sendmail.cf", > }, > } > > }I think the original proposal was due to legibility.> > In any case, this is just an example (and, in this case, a solution > or > another I guess it''s mostly a matter of personal taste). > Another point quite critical, according to me, is the standardization > of modules that need to manage objects provided by other modules. > An example could be a module for a software like mailcanner or amavis > or whatever: they should handle configuration files and other objects > of different other programs (for example an MTA like postfix, mail > filters like spamassassin and clamav and so on). > How can this be handled in a modular standard way (the mantainer of > mailscanner module is not necessarily the postfix mantainer)? > I''ve thought about different scenarios but they all require some > tweaks that can be more or less acceptable (for example a conflict > with other modules).This is where overrides would come in. The amavis module would have classes that inherit and override the MTA classes. But how to do so in a manner such that the MTA in use can be anything and that the amavis module doesn''t need to know about the MTA specifics is a challenge and one that isn''t quite clear how best to handle. Right now, in our case, we just craft everything specific to the MTA that we use (postfix) so we would not be able to swap out to sendmail by simply changing the package name in one manifest: we would need to make additional changes b/c config files are different, etc. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
----- "Luke Kanies" <luke@madstop.com> wrote:> Are your classes really getting that long? > > And does it really make sense to split them based on resource type, > rather than some other organizational criteria? > > The cfengine community was often hampered by a tendency to organize by > > action type rather than functional role, so I consider it a kind of > code smell in Puppet. >To manage Zimbra, we have 790 lines of code in our manifests. That being said, I wholeheartedly agree with you. I''m a staunch advocate of making sure people are doing things "the Puppet way" instead of forcing Puppet to bend to their own will. I''ll meet with my team and have them reevaluate their practice and see if there are better functional breaks that can make. The majority of the breaks in Zimbra module are definitely along the times of functional role, like LDAP, mailers, etc. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
----- "Kenton Brede" <kbrede@gmail.com> wrote:> My question is, what''s wrong with this setup? I ask this realizing > the smallness of our > operation makes me a little myopic.With a small operation, it is okay. With something larger, it doesn''t scale well and it doesn''t make good use of module grouping. For instance, when setting up openldap, I want to talk about what I do (packages I install, conf files I drop in, etc) all in one place so I can see what I do with openldap as a whole more easily. If it were broken out into several places based on OS type, it isn''t quite as easy to ensure that each OS type is similar. For instance, on a debian box and a redhat box, I can look at classes.txt and see that openssh class is applied, so I know that I''m managing openssh on debian and redhat boxes, but with the other approach, I wouldn''t be able to see that without digging into the debian.pp and redhat.pp files. And to the scaling point, we manage 2755 files so it would be difficult to manage manifests with all of that in one place.> > > The cfengine community was often hampered by a tendency to organize > by > > action type rather than functional role, so I consider it a kind of > > code smell in Puppet. > > Could you give a couple examples of what you mean by "action type" > and > "functional role?" > Thanks, > KentAn action type is like sort of like "what you do to a system." So, things like "install this file" or "install this package." Functional role is things like "manage openldap" or "ensure these users are present" which would in turn include actions like installing packages or files or setting up user preferences. -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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 Mon, Sep 29, 2008 at 1:30 PM, Digant C Kasundra <digant@stanford.edu> wrote:> > > ----- "Kenton Brede" <kbrede@gmail.com> wrote: > >> My question is, what''s wrong with this setup? I ask this realizing >> the smallness of our >> operation makes me a little myopic. > > With a small operation, it is okay. With something larger, it doesn''t scale well and it doesn''t make good use of module grouping. For instance, when setting up openldap, I want to talk about what I do (packages I install, conf files I drop in, etc) all in one place so I can see what I do with openldap as a whole more easily. If it were broken out into several places based on OS type, it isn''t quite as easy to ensure that each OS type is similar. For instance, on a debian box and a redhat box, I can look at classes.txt and see that openssh class is applied, so I know that I''m managing openssh on debian and redhat boxes, but with the other approach, I wouldn''t be able to see that without digging into the debian.pp and redhat.pp files. >Hmmm, unless I''m missing something, what you describe is what I''m doing. If I''m wrong please let me know. Currently I have two types of modules: Modules based on type (file, cron, etc) that are not tied to a particular service. For example, a custom script that goes to host foo, or a group such as rhel5. And modules based on a service (apache, iptables, etc), which contain any resources that are needed. The only time I have a rhel5.pp class, is if it''s as sub-module. For example cron::rhel5.pp, which contains cron jobs for rhel5 servers. Or apache::rhel5.pp, which contains rhel5 specifics for that group. I don''t have a single class rhel5.pp where I try to manage all resources, if that''s what you thought I did. <snip>>> Could you give a couple examples of what you mean by "action type" >> and >> "functional role?"> An action type is like sort of like "what you do to a system." So, things like "install this file" or "install this package." Functional role is things like "manage openldap" or "ensure these users are present" which would in turn include actions like installing packages or files or setting up user preferences. >Thanks for the clarification :) Kent --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
----- "Kenton Brede" <kbrede@gmail.com> wrote:> > With a small operation, it is okay. With something larger, it > doesn''t scale well and it doesn''t make good use of module grouping. > For instance, when setting up openldap, I want to talk about what I do > (packages I install, conf files I drop in, etc) all in one place so I > can see what I do with openldap as a whole more easily. If it were > broken out into several places based on OS type, it isn''t quite as > easy to ensure that each OS type is similar. For instance, on a > debian box and a redhat box, I can look at classes.txt and see that > openssh class is applied, so I know that I''m managing openssh on > debian and redhat boxes, but with the other approach, I wouldn''t be > able to see that without digging into the debian.pp and redhat.pp > files. > > > > Hmmm, unless I''m missing something, what you describe is what I''m > doing. If I''m wrong please let me know. > > Currently I have two types of modules: > > Modules based on type (file, cron, etc) that are not tied to a > particular service. For example, a custom script that goes to host > foo, or a group such as rhel5. And modules based on a service > (apache, iptables, etc), which contain any resources that are needed. > > The only time I have a rhel5.pp class, is if it''s as sub-module. For > example cron::rhel5.pp, which contains cron jobs for rhel5 servers. > Or apache::rhel5.pp, which contains rhel5 specifics for that group. > I > don''t have a single class rhel5.pp where I try to manage all > resources, if that''s what you thought I did. > > <snip>That is indeed what I thought you were doing. Phew. Yes, what you are doing seems logical. We don''t currently break things down into OS. Instead, our apache and apache::foo and whatnot all have internal logic to handle different operating systems with case statements. But what you''re doing is something I''ve seen other people doing and it seems pretty good to. Doesn''t quite fit my view of how I organize things in my head but that doesn''t necessarily make it "wrong."> >> Could you give a couple examples of what you mean by "action type" > >> and > >> "functional role?" > > > An action type is like sort of like "what you do to a system." So, > things like "install this file" or "install this package." Functional > role is things like "manage openldap" or "ensure these users are > present" which would in turn include actions like installing packages > or files or setting up user preferences. > > > > Thanks for the clarification :) > KentNo problem! -- Digant C Kasundra <digant@stanford.edu> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---