This is an interesting approach and certainly valid and should work. I'm not sure I would use the virtual resources since one could just as easily define those things in the classes they are used in. Virtual resources are better when you wnat to declare something in one place but it could be realized in any number of places (making it impossible to be declared in all of those places b/c if two such classes were included, you'd have an error)
I think having the OS specific subclasses override the package name instead of a large case statement in the initial package declaration is spiffy. I can actually seeing both ways being useful. Sometimes, I like to see all the various ways a package (or service) might look in one place, so I sometimes like to see the case statement approach. Other times, I like to see specific changes that are related to an OS or similar logical grouping to be made in an appropriate subclass with the use of overrides. To answer about use-cases, we have in our ssh module some subclasses that are relevent to a particular configuration of ssh server. For instance, ssh::global allows ssh connections from off campus while our regular ssh doesn't. I prefer these as subclasses b/c I like to look at my list of classes to glean what kinds of things my server is setup to do (and when I build an external node tool, rather than messing with variables and blah blah blah, I'll just be adding or dropping classes). ----- "Jeroen van Meeuwen" <[EMAIL PROTECTED]> wrote: > Hi there, > > I'd like to collect some feedback on a conceptual simple Puppet Common > > Module I want to propose; > > http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH > > I'm thinking about things like; > > - the way virtual resources are used, > - the way operating system specific sub-classes are used, > - use-cases I haven't met (although secondary), > - simple errors I've made (I whipped this up from the top of my head), > > although the best thing is maybe to jump on the Wiki and correct my > error, > - further enhancements in making this a really viable PCM. > > I guess what is not needed (yet) includes (I'm sorry if this sound > harsh); > > - discussions about the indentation I used > > I can live with any form of indentation, and I guess so can you. I > *just > so happen* to use 4 spaces to a tab. > > - the way I aggregate types into resources > > It to me is a habit / matter of convenience, while I'd like to focus > the > discussion on technical arguments instead. > > - namespacing of modules or classes > > again I can live with *any* namespacing, and it's not about setting > the > defacto standard for all Puppet Common Modules, it's about making a > *start* in "code". > > - module or class extensions that everyone uses > > because these often-used extensions should go *in* the module > (upstream, > upstream, upstream is my motto), and such can only be done when there > is > an upstream module to begin with. > > Thanks in advance for review/comments, > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > > -- Digant C Kasundra <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
