On Fri, Jan 7, 2011 at 12:39 PM, R.I.Pienaar <r...@devco.net> wrote:
>
>
> ----- Original Message -----
> > On Fri, Jan 7, 2011 at 2:47 AM, luke.bigum <
> > luke.bi...@fasthosts.co.uk > wrote:
> >
> >
> >
> > Hi list,
> >
> > Reading the thread "can a class require an other class?" it's been
> > mentioned that perhaps one way forward for the Puppet language is to
> > phase out the include keyword in favour of parametrised classes. I'm
> > thinking of my Puppet and the several levels of include chaining I use
> > and I'm wondering how on earth that'd be possible. Maybe I'm designing
> > my modules very differently to other people?
> >
> > I'll throw you an edited example from my environment and if the people
> > who favour parametrised classes over includes could show me their
> > alternatives that would be much appreciated. I haven't mentioned
> > resources because the class names are pretty self explanatory - each
> > class handles any package, service and config files related to it's
> > name:
> >
> > node 'somenode' {
> > include puppetmaster
> > }
> >
> > class puppetmaster {
> > include common
> > include puppet
> > include ldap_auth
> > include iptables::disabled
> > include httpd::ssl
> > include ruby-enterprise::passenger
> > }
> >
> > class ruby-enterprise::passenger {
> > include common
> > include httpd
> > include ruby-enterprise
> > }
> >
> > class httpd::ssl {
> > include httpd
> > }
> >
> >
> > The issue I'm trying to address is the current problem with scoping.
> > Considering class common, it will be nested inside of the puppetmaster
> > OR the ruby-enterprise::passenger class and it's not clear which one.
> > Behavior can change depending on which if variables or resource
> > defaults are being referenced outside the scope of class common.
> >
> > My recommendation is to try and make sure common classes, like class
> > "common" are only included in one place that make sense for you. I
> > would personally write this collection of classes as:
> >
> > (Note, this may be over-specifying dependency relationships, but
> > ideally this shouldn't be a huge problem for you if resources aren't
> > establishing direct relationships with resources in other classes. Run
> > stages may also be a good substitute for the require metaparameter on
> > classes.)
> >
> > Also, I'm totally open to suggestions to improve this organization
> > scheme, it clearly has issues but it's the best I've come up so far
> > and works well across the largest subset of Puppet deployments I've
> > worked with.
> >
> > node 'somenode' {
> >
> > class { common: }
> >
> > class { [ "ldap_auth",
> > "puppet",
> > "iptables::disabled",
> > "httpd",
> > "ruby-enterprise" ]: require => Class[common],
> > }
> >
> > class { puppetmaster: require => Class[puppet] }
> >
> > class { "httpd::ssl": require => Class[httpd] }
> >
> > class { "ruby-enterprise::passenger":
> > require => Class["ruby-enterprise", "httpd"]
> > }
> >
> > }
>
>
> dont you find having to specify the relationships of httpd::ssl and httpd
> here to be wrong?
>
No, not wrong. Certainly not ideal, but the best I can come up with with
the current language features.
> Isn't the fact that the httpd module is designed to have this ordering
> requirement an implementation detail and not a usage detail?
>
Yes. How can I re-factor this to move the ordering into the implementation
_without_ running into the scoping issues?
Surely people who just want to use the httpd module do not need to know this
> implementation detail? They should just be able to say use the module
> without understanding or knowing the ordering of internals.
>
I fully agree this is how things should be.
> If the internals of the modules are designed such that they require
> ordering of the sub classes then that is up to that module to specify in it.
> People who download from the forge should not need to concern themselves
> with this.
>
> It's also not very DRY.
>
So I agree with every issue you've raised, but you haven't proposed any
suggestions that address the scoping issues I'm trying to address and avoid.
Scoping issues trump the inconvenience of specifying this sort of thing when
using the classes.
--
Jeff McCune
http://www.puppetlabs.com/
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
