>
> You are about to blow your foot off, or at least your little toe. You
> cannot include a parameterized class twice, not even with the same
> parameters, and certainly not with different parameters. That will
> scuttle catalog compilation for node nfsserver.
>
> If you abandon class parameterization then you can do this with class
> inheritance, but the two do not work well together. The class
> inheritance approach might look something like this:
>
> class nfs {
> include nfs::params, nfs::install, nfs::config, nfs::service
> }
>
> class nfs::service::enabled inherits nfs::service {
> # Override Service['nfs'] to ensure it enabled and running
> }
>
> node basenode {
> include nfs
> ...
> }
>
> node nfsserver inherits basenode {
> include nfs::service::enabled
> }
>
That looks good to me, easy to understand, which makes me feel stupid for not
thinking about it myself.
>
> Alternatively, you can make basenode not include class nfs, leaving
> the choice of class parameters to the more specific node types, but
> then every one of them must include class nfs itself.
>
> Or you could use external data, such as obtained via extlookup() or
> hiera, to define whether nodes should be enabled as NFS servers. That
> would not only allow you to dispense with class nfs's parameters, but
> probably you could also drop node nfsserver.
Extlookup has been on my todo-list for a while, I just figured I'd try to get a
better feel for the basics before I go there.
>
> In general (says me), you should avoid defining class parameters whose
> purpose is to tweak the *meaning* of the class, such as your $client
> and $server parameters. That sort of purpose is better served by
> providing distinct classes. As a rule of thumb, do not define class
> parameters whose values are not intended to end up as [part of]
> resource property values. (That's supposing you have already decided
> to ignore my maxim #1 of Puppet class parameterization: don't do it.)
I haven't really decided anything yet, I'm certainly not set on using
parameterized classes, I'm mostly trying to find the Right Way to do things.
>
> Using external data to tweak the meaning of a class is at least better
> than using parameters for the same purpose. It causes the same kind
> of ambiguation of the class's meaning, but at least it doesn't
> introduce the practical limitations that come with class
> parameterization.
>
>
> John
Thanks for the input, I'll see if I can make the first way you suggested
working, seems easy enough. :)
Oh and sorry for the mail formatting...Outlook...
Regards
Johan
--
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.
