If that behaviour is changed, wouldn't this break the resources type?
On 18 December 2013 21:34, John Bollinger <john.bollin...@stjude.org> 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 >> <aurelien....@cea.fr>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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
