On Fri, Jan 7, 2011 at 1:41 PM, R.I.Pienaar <r...@devco.net> wrote:
> (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.
>
This is exactly what I have been recommending to people for variables.
The problem is that you can't manage the scope binding stacks in the same
way for resource defaults, or implicit tags.
I think that making resource defaults behave like variables in this sense
would go a long way to fixing the existing concerns with include.
ie:
in:
class foo {
include bar
File{mode => 777}
}
This resource default in foo should not effect resources in bar
> 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?
>
I agree with your point here about deprecating old features, but this is not
the only advantage of param classes, the other is that it specifies a real
interface:
class foo(
$bar, $baz, $bad
) {
...
}
is way better then:
# this excepts bar,baz, and bad
class foo{
...
}
I am not a big fan of extlookup for the same reason, it hides the interface
for a class as opposed to exposing it. (although this does work better with
dynamic scoping for reasons mentioned in this thread)
> > 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<puppet-users%2bunsubscr...@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<puppet-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
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.
