If that behaviour is changed, wouldn't this break the resources type?
On 18 December 2013 21:34, John Bollinger <[email protected]> wrote: > > > On Tuesday, December 17, 2013 1:05:09 PM UTC-6, Andy Parker wrote: > >> On Tue, Dec 17, 2013 at 7:42 AM, DEGREMONT Aurelien >> <[email protected]>wrote: >> >> >>> And I quickly workaround this using this oneliner patch: >>> >>> diff --git a/lib/puppet/type.rb b/lib/puppet/type.rb >>> index 1933097..bf09fdb 100644 >>> --- a/lib/puppet/type.rb >>> +++ b/lib/puppet/type.rb >>> @@ -681,7 +681,7 @@ class Type >>> # Provide the name, so we know we'll always refer to a real thing >>> result[:name] = self[:name] unless self[:name] == title >>> >>> - if ensure_prop = property(:ensure) or (self.class.validattr?(: >>> ensure) and ensure_prop = newattr(:ensure)) >>> + if ensure_prop = property(:ensure) or (self.class.validattr?(: >>> ensure) and ensure_prop = newattr(:ensure)) and ensure_prop.should >>> result[:ensure] = ensure_state = ensure_prop.retrieve >>> else >>> ensure_state = nil >>> >>> >>> What do you think of this? >>> >>> >> I tried it out. After unfortunately it changes the behavior of how puppet >> detects the current state of a resource on the system. You can see this >> pretty clearly when you use the "puppet resource" command to inspect >> something: >> >> > > Well that's the point, isn't it? Aurelien wants Puppet to avoid > evaluating the current state of the 'ensure' property of Service resources > where that property is unmanaged. > > At least, he wants the *agent* and presumably 'apply' to operate that > way. I suppose the current behavior is more sensible for the 'resource' > face. > > I think he has a point, and a more general one than just about the > Service.ensure property. The state-probing behavior appropriate for the > 'resource' face and maybe some others is not necessarily ideal for the > 'agent' and 'apply' faces. In some cases it may require little or no extra > effort to determine the current state of unmanaged properties, but in other > cases doing so can be expensive and therefore should be avoided where > determining that state is not a desired or needful outcome. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/d757615b-f8a0-4a23-983e-f04301f950bc%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- Erik Dalén -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLdgeW5wVBciyQnqDB_KyuDcw72jz1dVvrt%3DLJrPciD4fw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
