Puppet users - Jul 2010 - Reconciling resource defaults, dynamic scope, and the singleton nature of classes

Hello,

I''ve been thinking about how best to handle the situation where a
single class is included multiple times from multiple classes who
themselves set resource defaults.  This situation poses an interesting
problem in Puppet because of dynamic scoping rather than lexical
scoping and appears to come up frequently as I travel and work with
the puppet community.  It''s also come up quite a bit in my own work
and development of modules for the forge.

I''m looking for feedback from the community as to how best to handle
the unique situation in a maintainable and elegant manner.

This is pretty long, but it''s a rather complex problem and fairly
common in my experience, so thanks in advance for taking the time to
read through if you do.

I believe an use case will illustrate the point.

Consider a module, perhaps publicly available in the Forge, which is
extremely common and many other modules require.  A good example is
the configuration of the packaging system for the node to use a local
repository.

# /etc/puppet/modules/localpackagerepository/manifests/init.pp
class localpackagerepository {
  $module = "localpackagerepository"
  file { "/etc/yum/yum.repos.d/local.repo": source =>
"puppet:///modules/${module}/local.repo"; }
}

Other classes will likely establish a relationship in the graph to
this localpackagerepository class to ensure custom packages are
available before trying to manage their state.  For example:

# /etc/puppet/modules/apache/manifests/init.pp
class apache {
  $module = "apache"
  include localpackagerepository
  File {
    owner => "apache",
    group => "apache",
    require => Package["apache"],
    notify => Service["apache"],
  }
  ###
  package { "apache":
    ensure => installed,
    require => Class["localpackagerepository"];
  }
  service { "apache": ensure => running }
  file { "/etc/httpd/httpd.conf": source =>
"puppet:///modules/${module}/apache.conf"; }
}

# /etc/puppet/modules/postfix/manifests/init.pp
class postfix {
  $module = "postfix"
  include localpackagerepository
  File {
    owner => "mail",
    group => "mail",
    require => Package["postfix"],
    notify => Service["postfix"],
  }
  package { "postfix":
    ensure => installed,
    require => Class["localpackagerepository"];
  }
  service { "postfix": ensure => running; }
  file { "/etc/postfix/main.cf": source =>
"puppet:///modules/${module}/main.cf"; }
}

Now, with these three modules we may include them in the node
classification like so:
include apache
include postfix

However, this will behave very differently than the classes included
in a different order:
include postfix
include apache

In the first ordering the localpackagerepository class will take on
the resource defaults of the apache class, while in the second
ordering the localpackagerepository class will take on the resource
defaults of the postfix class.

In both cases there will be a circular dependency (local.repo will
require a package, and the package will require local.repo), which is
clearly an issue.  In either case, local.repo will take on defaults
for owner and group which are invalid.

How are you handling this situation?  How do you think this situation
*should* be handled by puppet?

I can think of a number of work arounds, but they''re not ideal and
they don''t feel to me like they''ll play well with public
modules
posted to the forge.

I make the recommendation that classes should include the classes they
depend on, but this appears to be problematic if the class doing the
include sets resource defaults, particularity when setting a
relationship in a default like require, before, subscribe and notify.
This opens up the door for resource cycles.

Perhaps it might be useful to set resource defaults only for the local
scope, and not for any classes which get included into this scope.
How do you feel about this change to the language?

Is there some other organization of the class structure I''m
overlooking?

Thanks for your feedback,
-- 
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
> I make the recommendation that classes should include the classes
> they depend on, but this appears to be problematic if the class doing the
> include sets resource defaults, particularity when setting a
> relationship in a default like require, before, subscribe and notify.
> This opens up the door for resource cycles.
recommendations are fine, but that is a lot of convention and best 
practice something that is very hard to pass on to new people, its hard
to audit and its hard to predict.  And ones established as a best practise
that causes problems when ignored also lulls one into a false sense of
safety.

best avoided, it should do the right thing by default.
> Perhaps it might be useful to set resource defaults only for the
> local scope, and not for any classes which get included into this scope.
> How do you feel about this change to the language?
I''ve thought about this problem before and thought the fact that puppet
did not behave in this way was a bug, so my vote is with this :)

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune <jeff@puppetlabs.com> wrote:
> Perhaps it might be useful to set resource defaults only for the local
> scope, and not for any classes which get included into this scope.
> How do you feel about this change to the language?
So this would mean that you''d only be able to set truly global
resource defaults with an import in site.pp? and no longer inside a
base class that includes all your other classes?

We make use of the current behavior of defaults being applied to
included classes quite a lot, and I find it useful just to provide a
counterpoint to RIP :)
>
> Is there some other organization of the class structure I''m
overlooking?
>
> Thanks for your feedback,
> --
> 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-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
nigel

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net>
wro>
> ----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
>
>> I make the recommendation that classes should include the classes
>> they depend on, but this appears to be problematic if the class doing
the
>> include sets resource defaults, particularity when setting a
>> relationship in a default like require, before, subscribe and notify.
>> This opens up the door for resource cycles.
>
> recommendations are fine, but that is a lot of convention and best
> practice something that is very hard to pass on to new people, its hard
> to audit and its hard to predict.  And ones established as a best practise
> that causes problems when ignored also lulls one into a false sense of
> safety.
Agreed.  As you mentioned this has been on my mind for quite a while
now.  The unpredictability of scope when a class is included multiple
times has been pushed to front of my mind since it''s been such a
common point of confusion when talking with many people, both new and
experienced.
> best avoided, it should do the right thing by default.
Agreed.  This begs the question; what is the "right thing" puppet
should be doing by default?
>> Perhaps it might be useful to set resource defaults only for the
>> local scope, and not for any classes which get included into this
scope.
>> How do you feel about this change to the language?
>
> I''ve thought about this problem before and thought the fact that
puppet
> did not behave in this way was a bug, so my vote is with this :)
Do you think resource defaults should default to the local scope if
the default isn''t declared in the top or node scope?

Perhaps it would be sufficient to prevent "include" from granting
access to the local scope and instead limit scope to namespaces and
class inheritance?

I''m not too familiar with the code inside of puppet at this level, so
it may be far more sensible to just introduce a "local" keyword to
declare resource defaults in the local scope only, but I''m not sure
this wouldn''t satisfy the "behave by default" goal we have.

-- 
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 12:37 PM, Nigel Kersten <nigelk@google.com>
wrote:
> On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune <jeff@puppetlabs.com>
wrote:
>
>> Perhaps it might be useful to set resource defaults only for the local
>> scope, and not for any classes which get included into this scope.
>> How do you feel about this change to the language?
>
> So this would mean that you''d only be able to set truly global
> resource defaults with an import in site.pp? and no longer inside a
> base class that includes all your other classes?
>
> We make use of the current behavior of defaults being applied to
> included classes quite a lot, and I find it useful just to provide a
> counterpoint to RIP :)
How do you "know" what the scope is of those included classes will end
up as?  Are you not including the "edge" classes multiple times?

-- 
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 11:51 AM, Jeff McCune <jeff@puppetlabs.com>
wrote:
> On Thu, Jul 29, 2010 at 12:37 PM, Nigel Kersten <nigelk@google.com>
wrote:
>> On Thu, Jul 29, 2010 at 10:48 AM, Jeff McCune
<jeff@puppetlabs.com> wrote:
>>
>>> Perhaps it might be useful to set resource defaults only for the
local
>>> scope, and not for any classes which get included into this scope.
>>> How do you feel about this change to the language?
>>
>> So this would mean that you''d only be able to set truly global
>> resource defaults with an import in site.pp? and no longer inside a
>> base class that includes all your other classes?
>>
>> We make use of the current behavior of defaults being applied to
>> included classes quite a lot, and I find it useful just to provide a
>> counterpoint to RIP :)
>
> How do you "know" what the scope is of those included classes
will end
> up as?  Are you not including the "edge" classes multiple times?
Nope. That would be insane due to what sparked this thread off :)


-- 
nigel

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net> wro>
> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
> >
> >> I make the recommendation that classes should include the classes
> >> they depend on, but this appears to be problematic if the class
> doing the
> >> include sets resource defaults, particularity when setting a
> >> relationship in a default like require, before, subscribe and
> notify.
> >> This opens up the door for resource cycles.
> >
> > recommendations are fine, but that is a lot of convention and best
> > practice something that is very hard to pass on to new people, its
> hard
> > to audit and its hard to predict.  And ones established as a best
> practise
> > that causes problems when ignored also lulls one into a false sense
> of
> > safety.
> 
> Agreed.  As you mentioned this has been on my mind for quite a while
> now.  The unpredictability of scope when a class is included multiple
> times has been pushed to front of my mind since it''s been such a
> common point of confusion when talking with many people, both new and
> experienced.
> 
> > best avoided, it should do the right thing by default.
> 
> Agreed.  This begs the question; what is the "right thing" puppet
> should be doing by default?
> 
> >> Perhaps it might be useful to set resource defaults only for the
> >> local scope, and not for any classes which get included into this
> scope.
> >> How do you feel about this change to the language?
> >
> > I''ve thought about this problem before and thought the fact
that
> puppet
> > did not behave in this way was a bug, so my vote is with this :)
> 
> Do you think resource defaults should default to the local scope if
> the default isn''t declared in the top or node scope?
I had not considered the global scope defaults, I dont use them cos I
like the side effect of a manifest to be clear when looking at a single
pp file.  I''d only ever set a default that I expect to be localized 
to the class its in.  but thats just me as Nigel points out :)

> Perhaps it would be sufficient to prevent "include" from granting
> access to the local scope and instead limit scope to namespaces and
> class inheritance?
> 
> I''m not too familiar with the code inside of puppet at this level,
so
> it may be far more sensible to just introduce a "local" keyword
to
> declare resource defaults in the local scope only, but I''m not
sure
> this wouldn''t satisfy the "behave by default" goal we
have.
> 
I guess so, it sounds all a bit magic really.  If this doable then kewl,
otherwise some new syntax for indicating global scoped defaults.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar <rip@devco.net>
wrote:
>
> ----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
>
>> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <rip@devco.net>
wro>
>> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
>> >
>> >> I make the recommendation that classes should include the
classes
>> >> they depend on, but this appears to be problematic if the
class
>> doing the
>> >> include sets resource defaults, particularity when setting a
>> >> relationship in a default like require, before, subscribe and
>> notify.
>> >> This opens up the door for resource cycles.
>> >
>> > recommendations are fine, but that is a lot of convention and best
>> > practice something that is very hard to pass on to new people, its
>> hard
>> > to audit and its hard to predict.  And ones established as a best
>> practise
>> > that causes problems when ignored also lulls one into a false
sense
>> of
>> > safety.
>>
>> Agreed.  As you mentioned this has been on my mind for quite a while
>> now.  The unpredictability of scope when a class is included multiple
>> times has been pushed to front of my mind since it''s been such
a
>> common point of confusion when talking with many people, both new and
>> experienced.
>>
>> > best avoided, it should do the right thing by default.
>>
>> Agreed.  This begs the question; what is the "right thing"
puppet
>> should be doing by default?
>>
>> >> Perhaps it might be useful to set resource defaults only for
the
>> >> local scope, and not for any classes which get included into
this
>> scope.
>> >> How do you feel about this change to the language?
>> >
>> > I''ve thought about this problem before and thought the
fact that
>> puppet
>> > did not behave in this way was a bug, so my vote is with this :)
>>
>> Do you think resource defaults should default to the local scope if
>> the default isn''t declared in the top or node scope?
>
> I had not considered the global scope defaults, I dont use them cos I
> like the side effect of a manifest to be clear when looking at a single
> pp file.  I''d only ever set a default that I expect to be
localized
> to the class its in.  but thats just me as Nigel points out :)
So we only do it for quite specific cases, turning off file backups
and forcing application, ensuring our desired provider is explicit
(we''ve had the odd issue where the automatic provider selection
didn''t
behave the way we wanted) and ensuring that our apt packages all
require our "update-apt-stuff" class.

File { force => true, backup => false, }

  Package {
    provider => "apt",
    require  => Class["package::apt::update"]
  }

We basically have provider defaults explicitly set as global resource
defaults for package and service for each of our platforms.

I have had the odd situation where I couldn''t use a resource default
due to the scope inheritance, but that''s it. The vast majority of our
defaults are either global, or in a class that doesn''t include any
other classes. The latter case we do for readability and to reduce
fat-fingering.
>
>
>> Perhaps it would be sufficient to prevent "include" from
granting
>> access to the local scope and instead limit scope to namespaces and
>> class inheritance?
>>
>> I''m not too familiar with the code inside of puppet at this
level, so
>> it may be far more sensible to just introduce a "local"
keyword to
>> declare resource defaults in the local scope only, but I''m not
sure
>> this wouldn''t satisfy the "behave by default" goal
we have.
>>
>
> I guess so, it sounds all a bit magic really.  If this doable then kewl,
> otherwise some new syntax for indicating global scoped defaults.
>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
nigel

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Nigel Kersten" <nigelk@google.com> wrote:
> On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar <rip@devco.net> wrote:
> >
> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
> >
> >> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar
<rip@devco.net> wro>
> >> > ----- "Jeff McCune" <jeff@puppetlabs.com>
wrote:
> >> >
> >> >> I make the recommendation that classes should include the
> classes
> >> >> they depend on, but this appears to be problematic if the
class
> >> doing the
> >> >> include sets resource defaults, particularity when
setting a
> >> >> relationship in a default like require, before, subscribe
and
> >> notify.
> >> >> This opens up the door for resource cycles.
> >> >
> >> > recommendations are fine, but that is a lot of convention and
> best
> >> > practice something that is very hard to pass on to new
people,
> its
> >> hard
> >> > to audit and its hard to predict.  And ones established as a
> best
> >> practise
> >> > that causes problems when ignored also lulls one into a false
> sense
> >> of
> >> > safety.
> >>
> >> Agreed.  As you mentioned this has been on my mind for quite a
> while
> >> now.  The unpredictability of scope when a class is included
> multiple
> >> times has been pushed to front of my mind since it''s been
such a
> >> common point of confusion when talking with many people, both new
> and
> >> experienced.
> >>
> >> > best avoided, it should do the right thing by default.
> >>
> >> Agreed.  This begs the question; what is the "right
thing" puppet
> >> should be doing by default?
> >>
> >> >> Perhaps it might be useful to set resource defaults only
for
> the
> >> >> local scope, and not for any classes which get included
into
> this
> >> scope.
> >> >> How do you feel about this change to the language?
> >> >
> >> > I''ve thought about this problem before and thought
the fact that
> >> puppet
> >> > did not behave in this way was a bug, so my vote is with this
:)
> >>
> >> Do you think resource defaults should default to the local scope
> if
> >> the default isn''t declared in the top or node scope?
> >
> > I had not considered the global scope defaults, I dont use them cos
> I
> > like the side effect of a manifest to be clear when looking at a
> single
> > pp file.  I''d only ever set a default that I expect to be
localized
> > to the class its in.  but thats just me as Nigel points out :)
> 
> So we only do it for quite specific cases, turning off file backups
> and forcing application, ensuring our desired provider is explicit
> (we''ve had the odd issue where the automatic provider selection
> didn''t
> behave the way we wanted) and ensuring that our apt packages all
> require our "update-apt-stuff" class.
> 
> File { force => true, backup => false, }
I think this should be a configuration option tbh - to disable backups, not
force :)
>   Package {
>     provider => "apt",
>     require  => Class["package::apt::update"]
>   }
> 
> We basically have provider defaults explicitly set as global resource
> defaults for package and service for each of our platforms.
I''ve wrapped all my package access in a define that does this kind of
thing
among others, but it just means i can control all the specific behavior in 
one place and if i get a new site or new needs its one update.

I do this with quite a lot of things, all about explicit behavior and not 
side effects of something not visible in diff''s being mailed by post
commit
hooks.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 12:28 PM, R.I.Pienaar <rip@devco.net>
wrote:
>
> ----- "Nigel Kersten" <nigelk@google.com> wrote:
>
>> On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar <rip@devco.net>
wrote:
>> >
>> > ----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
>> >
>> >> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar
<rip@devco.net> wro>
>> >> > ----- "Jeff McCune" <jeff@puppetlabs.com>
wrote:
>> >> >
>> >> >> I make the recommendation that classes should include
the
>> classes
>> >> >> they depend on, but this appears to be problematic if
the class
>> >> doing the
>> >> >> include sets resource defaults, particularity when
setting a
>> >> >> relationship in a default like require, before,
subscribe and
>> >> notify.
>> >> >> This opens up the door for resource cycles.
>> >> >
>> >> > recommendations are fine, but that is a lot of convention
and
>> best
>> >> > practice something that is very hard to pass on to new
people,
>> its
>> >> hard
>> >> > to audit and its hard to predict.  And ones established
as a
>> best
>> >> practise
>> >> > that causes problems when ignored also lulls one into a
false
>> sense
>> >> of
>> >> > safety.
>> >>
>> >> Agreed.  As you mentioned this has been on my mind for quite a
>> while
>> >> now.  The unpredictability of scope when a class is included
>> multiple
>> >> times has been pushed to front of my mind since it''s
been such a
>> >> common point of confusion when talking with many people, both
new
>> and
>> >> experienced.
>> >>
>> >> > best avoided, it should do the right thing by default.
>> >>
>> >> Agreed.  This begs the question; what is the "right
thing" puppet
>> >> should be doing by default?
>> >>
>> >> >> Perhaps it might be useful to set resource defaults
only for
>> the
>> >> >> local scope, and not for any classes which get
included into
>> this
>> >> scope.
>> >> >> How do you feel about this change to the language?
>> >> >
>> >> > I''ve thought about this problem before and
thought the fact that
>> >> puppet
>> >> > did not behave in this way was a bug, so my vote is with
this :)
>> >>
>> >> Do you think resource defaults should default to the local
scope
>> if
>> >> the default isn''t declared in the top or node scope?
>> >
>> > I had not considered the global scope defaults, I dont use them
cos
>> I
>> > like the side effect of a manifest to be clear when looking at a
>> single
>> > pp file.  I''d only ever set a default that I expect to be
localized
>> > to the class its in.  but thats just me as Nigel points out :)
>>
>> So we only do it for quite specific cases, turning off file backups
>> and forcing application, ensuring our desired provider is explicit
>> (we''ve had the odd issue where the automatic provider
selection
>> didn''t
>> behave the way we wanted) and ensuring that our apt packages all
>> require our "update-apt-stuff" class.
>>
>> File { force => true, backup => false, }
>
> I think this should be a configuration option tbh - to disable backups, not
force :)
Ah, but we have the odd little file that we do choose to backup :) so
a default makes sense here.
>
>>   Package {
>>     provider => "apt",
>>     require  => Class["package::apt::update"]
>>   }
>>
>> We basically have provider defaults explicitly set as global resource
>> defaults for package and service for each of our platforms.
>
> I''ve wrapped all my package access in a define that does this kind
of thing
> among others, but it just means i can control all the specific behavior in
> one place and if i get a new site or new needs its one update.
>
> I do this with quite a lot of things, all about explicit behavior and not
> side effects of something not visible in diff''s being mailed by
post commit
> hooks.
I''m also moving things to defines rather than resource defaults,
primarily because you can append to the relationships rather than
replacing them, but I''m not sure it''s any more explicit to
have to go
look at the definition rather than resource default? I guess if you''re
using defaults in a non-sane manner it might be :)


>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 
nigel

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 12:58 PM, Nigel Kersten <nigelk@google.com> wrote:
> > How do you "know" what the scope is of those included
classes will end
> > up as?  Are you not including the "edge" classes multiple
times?
>
> Nope. That would be insane due to what sparked this thread off :)

I think this is something that is really becoming an issue with the
increasing number of modules published to the Forge.  Modules need some way
to satisfy their dependencies on other modules, and the current behavior of
include just doesn''t seem to cut it.

What about include ::localyumrepository ?

It''s valid syntax in 0.24.9, 0.25.5, and 2.6.0

And...  Believe it or not, it actually already does almost exactly what I
want it to do in 2.6, except I think I found a bug in 2.6.

Here''s my test manifest:
#
class leaf { notify { "leaf": } }
class baseone {
  Notify { message => "baseone" }
  notify { "baseone": }
  include ::leaf
}
class basetwo {
  Notify { message => "basetwo" }
  notify { "basetwo": }
  include ::leaf
}
include baseone, basetwo
# include basetwo, baseone

Here''s the result in 0.25.5 and 0.24.9:
notice: baseone
notice: //baseone/Notify[baseone]/message: defined ''message''
as ''baseone''
notice: baseone
notice: //baseone/leaf/Notify[leaf]/message: defined ''message''
as ''baseone''
notice: basetwo
notice: //basetwo/Notify[basetwo]/message: defined ''message''
as ''basetwo''

Notice how Notify[leaf]''s scope is within baseone, which was the first
class
to include it.

Now, for the pleasant surprise: (in 2.6.0)
notice: basetwo
notice: /Stage[main]/Basetwo/Notify[basetwo]/message: defined
''message'' as
''basetwo''
notice: baseone
notice: /Stage[main]/Leaf/Notify[leaf]/message: defined
''message'' as
''baseone''
notice: baseone
notice: /Stage[main]/Baseone/Notify[baseone]/message: defined
''message'' as
''baseone''

It *appears* Notify[leaf] is not within the scope of Baseone or Basetwo,
however it''s still getting the default value of the message parameter
from
the baseone class...  Flipping in the order around to include basetwo,
baseone we get:
notice: /Stage[main]/Leaf/Notify[leaf]/message: defined
''message'' as
''basetwo''

Again, it looks like the class is included into top scope, but the behavior
is that we''re still getting resource defaults from basetwo''s
scope.

Thoughts?  Am I insane for wanting include ::leaf to place Leaf at top
scope?

-- 
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- "Jeff McCune" <jeff@puppetlabs.com> wrote:
> 
> I think this is something that is really becoming an issue with the
> increasing number of modules published to the Forge. Modules need some
> way to satisfy their dependencies on other modules, and the current
> behavior of include just doesn''t seem to cut it.
> 
> 
> What about include ::localyumrepository ?
> 
> 
> It''s valid syntax in 0.24.9, 0.25.5, and 2.6.0
> 
> 
> And... Believe it or not, it actually already does almost exactly what
> I want it to do in 2.6, except I think I found a bug in 2.6.
> 
> 
> Here''s my test manifest:
> #
> 
> class leaf { notify { "leaf": } }
> class baseone {
> Notify { message => "baseone" }
> notify { "baseone": }
> include ::leaf
> }
> class basetwo {
> Notify { message => "basetwo" }
> notify { "basetwo": }
> include ::leaf
> }
> include baseone, basetwo
> # include basetwo, baseone
> 
> 
> Here''s the result in 0.25.5 and 0.24.9:
> 
> notice: baseone
> notice: //baseone/Notify[baseone]/message: defined
''message'' as
> ''baseone''
> notice: baseone
> notice: //baseone/leaf/Notify[leaf]/message: defined
''message'' as
> ''baseone''
> notice: basetwo
> notice: //basetwo/Notify[basetwo]/message: defined
''message'' as
> ''basetwo''
> 
> 
> Notice how Notify[leaf]''s scope is within baseone, which was the
first
> class to include it.
> 
> 
> Now, for the pleasant surprise: (in 2.6.0)
> 
> notice: basetwo
> notice: /Stage[main]/Basetwo/Notify[basetwo]/message: defined
> ''message'' as ''basetwo''
> notice: baseone
> notice: /Stage[main]/Leaf/Notify[leaf]/message: defined
''message'' as
> ''baseone''
> notice: baseone
> notice: /Stage[main]/Baseone/Notify[baseone]/message: defined
> ''message'' as ''baseone''
> 
> 
> It *appears* Notify[leaf] is not within the scope of Baseone or
> Basetwo, however it''s still getting the default value of the
message
> parameter from the baseone class... Flipping in the order around to
> include basetwo, baseone we get:
> 
> notice: /Stage[main]/Leaf/Notify[leaf]/message: defined
''message'' as
> ''basetwo''
> 
> 
> Again, it looks like the class is included into top scope, but the
> behavior is that we''re still getting resource defaults from
basetwo''s
> scope.
> 
> 
> Thoughts? Am I insane for wanting include ::leaf to place Leaf at top
> scope?
I think so :) ::topclass isnt about scope its about resolution? I never
considered it would have scope implications.

Only time you tend to see it is in:

class monitor { }
class foo::monitor { }
class foo::bar { include ::monitor }

to include class monitor and not foo::monitor, you wouldnt want that to do weird
scope things

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 2:00 PM, Jeff McCune <jeff@puppetlabs.com> wrote:
> And...  Believe it or not, it actually already does almost exactly what I
> want it to do in 2.6, except I think I found a bug in 2.6.
>
>
Hrm, it appears to be just a tweak to the display...

include leaf and include ::leaf both result in the same display of:
notice: /Stage[main]/Leaf/Notify[leaf]/message: defined
''message'' as
''baseone''

So it''s still nesting the scope of leaf, however it''s just no
longer clearly
displaying it.

Rats.

-- 
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Jul 29, 2010 at 2:04 PM, R.I.Pienaar <rip@devco.net>
wrote:
>
> I think so :) ::topclass isnt about scope its about resolution? I never
considered it would have scope implications.
Right, forgot about that case.

So what about another keyword in addition to require and include
(feels like we''re running out...) that adds a class to the catalog at
top scope?  Something like "addclass" perhaps.

Modules would then avoid using "include mydependency" and prefer
"addclass mydependency"

--
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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 7/29/2010 8:07 PM, R.I.Pienaar wrote:
>
> ----- "Jeff McCune"<jeff@puppetlabs.com>  wrote:
>> Perhaps it might be useful to set resource defaults only for the
>> local scope, and not for any classes which get included into this
scope.
>> How do you feel about this change to the language?
>
> I''ve thought about this problem before and thought the fact that
puppet
> did not behave in this way was a bug, so my vote is with this :)
+1. I was not aware of the current behaviour and it''s definitely not
the
way I''d expect a sensible language to work.


Best Regards, David
-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.