john.bollin...@stjude.org (jcbollinger) writes:
> On May 14, 8:52 am, Simon J Mudd <sjm...@pobox.com> wrote:
>
> > However, from the discussion a few things strike me:
> >
> > 1. the use of parameterised classes is recommended heavily. I've just
> > found out about this "new feature" inspite of using puppet for a long
> > time. Hence many recipes that I'm using are not paremeterised and I
> > have a large number of similar classes. This is certainly worth fixing
> > but is quite a painful transition to make given the number of systems
> > in use and the chance of creating heavy breakage during that change.
> > So if you haven't used parameterised classes much that's the first
> > thing that needs looking at.
>
> If you have a complex set of manifests that do not use parameterized
> classes, then I think it much safer to coalesce similar classes with
> the help of extlookup() than by attempting to switch to parameterized
> classes.
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.
So I'd like something like
$mount_point = lookup_by_regexp( 'mount_point', $hostname, 'regexp_file', '' )
# parameters: lookup_item, lookup_value, regexp file to lookup, default
$lvsize = lookup_by_regexp( 'lvsize', $hostname, 'regexp_file', '' )
class db_lvconfig { db_lvconfig: mount_point => $mount_point, lvsize => $lvsize
} # note: other default parameters not shown like: owner, group, mode, vgname,
lvname
and have in the .csv file something like
mount_point,/dbservera/,/mount_point/for/servera
mount_point,/dbserverb/,/mount_point/for/serverb
mount_point,/dbserverc/,/mount_point/for/serverc
lvsize,/dbservera/,100G
lvsize,/dbserverb/,200G
lvsize,/dbserverc/,300G
Then if $hostname = 'dbservera-001'
it would get $lvsize = '100G', and $mount_point = '/mount_point/for/servera'
If I have 10 dbservera-xxx boxes then this keeps the config simple and the
.csv files much smaller.
> There are a couple of important ways (other than
> parameterization itself) by which parameterized classes differ from
> non-parameterized ones, and the more complex your current manifests,
> the more likely these are to bite you if you parameterize existing
> classes.
Perhaps. for most of my cases I don't think that's the case. I'm
slowly adjusting the configuration of several classes to use
parameterised classes but even these still work nicely with
extlookup() alternatives such as the currently unimplemented
lookup_by_key() or lookup_by_regexp() alternatives I'm thinking of
using.
> Note, however, that it is the use of extlookup() *as an alternative to
> class parameterization* that the style guide recommends against. Do
> not take it as a blanket recommendation against using the feature.
I'm not. You need to have a very considered mindset to build
_everything_ top down using an ENC and classes or globalvariables. If
using global variables as heavily as puppet seem to imply then ensuing
that you have a clear naming policy for this is quite important to
avoid unexpected name clashes (or mistakes) which might go unnoticed.
So I'd certainly like to see real world examples of complete
configurations to be fully convinced this works well. Perhaps after
moving a configuration to use extlookup() type mechanisms it then
becomes easier to make a further step "up" to get to the ENCs style
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.
> 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.
I still tend to like the idea of:
class db_lvconfig { db_lvconfig: mount_point => $mount_point, lvsize => $lvsize
}
You shouldn't have to understand or worry about what's underneath this
definition
as long as the interface is clearly defined.
> > [...] if you already have working recipes
> > perhaps and aren't using an ENC [, extlookup] gives you a way to
> > clearly remove the conditional logic the recipes currently have. It's
> > then a smaller step "up" to using an ENC if you want to go that
> > way. For those that don't it still becomes reasonably clear where the
> > configuration is parameterised and how/why that's done, so it's still
> > a more flexible approach.
>
> I agree. Furthermore, I maintain that if you are not using an ENC,
> then parameterized classes offer few advantages to offset their
> disadvantages. Therefore, if you are not already using an ENC and do
> not want to switch to one right now, then extlookup() is the best
> generally available way to externalize your configuration's data.
I tend to agree.
Perhaps it's also a matter of scale and I don't work in a big enough
environment to see the need for an ENC, at least the way it seems to
be envisaged by Puppetlabs. It may well be that I'm not fully
understanding the message or doing things the right way, so if someone
can shed more light on this I'd be more than happy to learn some more.
Simon
--
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.
