(forced to top post due to your html email)
You cant avoid the scoping issues cos its broken. You can work around them
though.
You can be careful about where you set variables and how you include things.
This
isn't new we've been doing it for years.
You can use extlookup to fetch variables from your data store in the class you
need
it and not rely on setting variables in one scope and accessing them in others.
You can have some very simple syntax and style rules that says include classes
first
in your class then set variables to avoid the strange ordering issues.
You can create wrapper classes that include other classes but not set variables.
class apache includes apache::config, ::install and ::service and as above in
each
case where you need to know apache version or something you can get that from
extlookup
which gives you configurable classes today without the scoping issues.
By arranging modules like this - one class that exist only to include other
classes -
you totally avoid issues like setting defaults bleeding into other scopes. I
have 100+
modules and never even realized the defaults propagate over included classes
because
my coding style and standards simply doesnt allow that to happen.
We've avoided these issues for years and the techniques are well known.
Now when the language wish to get new features and improve itself you can
either introduce
a whole slew of new syntax, deprecate old syntax etc and new ways of writing
manifests
or you can fix the scoping problems which will result in existing techniques
and language
features working sanely?
> Scoping issues trump the inconvenience of specifying this sort of
> thing when using the classes.
Correct, lets fix the scoping issues that's creating a language that forces us
to write
non obvious, non DRY and code that is coupled in ways it shouldnt be coupled.
We cannot
now write really advanced modules that hide all the implimentation details even
though
the language has all it needs to do this. Whats preventing us from doing that
is the
scoping bugs. So I am not sure why we arent fixing these instead.
----- Original Message -----
> 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.
--
R.I.Pienaar
--
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.
