----- Original Message ----- > john.bollin...@stjude.org (jcbollinger) writes: > > Perhaps. To some extend my non-parameterised classes are _very_ similar > in many ways except for various parameters (creation of logical volumes > and filesystems, version of mysql to use, creation of certain cron jobs > for importing informtation into a configuration database, and other crons > for doing standard jobs, etc....) Most of the "completely common" stuff > has been taken out. However, using extlookup() doesn't really work for > me "right now" for a simple reason I haven't yet mentioned. I'd further > like to have a lookup_by_key() function [let's say similar to the extlookup() > one provided now] but also a lookup_by_regexp() function where I can match > groups of boxes, in my case mainly based on regexps of their hostnames > rather than on specific $hostname, or $domain, etc.... Without that > I need to add more entries to match by lots of hostnames, which > doesn't work.
I think you're really trying to just avoid thinking in the puppet way instead trying to force some previous ideas on how things should work on it rather than figure out how it works. For example, you could just define a fact on your machines that indicate what role they have - perhaps based on your regex hostnames - and then use that in extlookup to select csv file to use. That would achieve your goal and it would be the puppet way of solving it. > Puppetlabs reccommends. However, with system configuration being a > continual ongoing process I tend to think that a 100% ENC-only style > build using only parameterised classes is going to be a hard thing to > achieve in practice. And the global variables just don't convince me > yet. Perhaps I still have to see the light. ENCs can (now) pass parameters to param classes. So you dont have to do it all with global vars. > > Note also that another part of the Style Guide's approach is that > > classes should avoid including other classes. Although it may not > > be > > immediately obvious, that goes hand-in-hand with extensive use of > > parameterized classes. Do take that into consideration as you > > evaluate the Style Guide's recommendations. > > Hm.. well building bigger blocks from smaller ones tends to be a good > practice to follow, so this recommendation seems counterintuitive. > I'll have to lookup the section and see if they explain why, but > guess it's because the intention is you build your server in terms of > smallish components. +1, I think this is mostly down to the bad design in param classes - they really do not promote the use of many small classes that creates a larger module. Making modules harder to read and making dependencies harder to specify. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
