On Thu, Jul 29, 2010 at 12:11 PM, R.I.Pienaar <[email protected]> wrote:
>
> ----- "Jeff McCune" <[email protected]> wrote:
>
>> On Thu, Jul 29, 2010 at 12:07 PM, R.I.Pienaar <[email protected]> wro>
>> > ----- "Jeff McCune" <[email protected]> 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
