On Thu, Jul 29, 2010 at 12:28 PM, R.I.Pienaar <[email protected]> wrote:
>
> ----- "Nigel Kersten" <[email protected]> wrote:
>
>> 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, }
>
> 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 [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.
