2008/9/25 Luke Kanies <[EMAIL PROTECTED]>: > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
