On Fri, Nov 21, 2008 at 9:19 AM, Luke Kanies <[EMAIL PROTECTED]> wrote:
>
> On Nov 21, 2008, at 10:52 AM, Nigel Kersten wrote:
>
>>
>> I was trying to track down why a manifest that looks like this for
>> my type:
>>
>> macauthorization {"system.device.dvd.setregion.initial":
>> ensure => present,
>> shared => true,
>> }
>>
>> kept telling me:
>>
>> notice: //Macauthorization[system.device.dvd.setregion.initial]/
>> shared:
>> shared changed 'true' to 'true'
>>
>> and some debugging in the property class showed that the current value
>> class is a TrueClass while the new value class is a Symbol.
>>
>> Should I need to do munging like this in the property definition, or
>> is this an indication something else is up with my type? like I'm not
>> symbolizing somewhere that I should be?
>>
>> newproperty(:shared) do
>> desc "shared"
>> newvalue(:true)
>> newvalue(:false)
>>
>> munge do |value|
>> case value
>> when true, "true", :true:
>> true
>> else
>> value
>> end
>> end
>> end
>>
>> The current value will always come out as a boolean from the backing
>> store.
>
>
> I agree there's something ridiculous going on here, but you shouldn't
> need to manually munge things.
>
> I'd start by adding debugging to your type to see where you've got the
> boolean and where you've got the symbol or whatever.
so my "shared" method in the provider returns a TrueClass.
my "shared=(value)" method is getting a Symbol.
I can work around this, but it isn't what I expected to happen.
>
> From the code, only strings are converted to symbols by default, but
> I think a limitation in the system caused me to start using symbols
> everywhere, and there's some kind of magic that that makes true/false
> work.
>
> For this, you might also try adding ':boolean => true' to the property
> declaration:
>
> newproperty(:shared, :boolean => true) do ... end
>
> This should actually be autodetected, but it's convenient in that it
> gives you a 'resource.shared?' method, which can be useful.
This works nicely actually, apart from not getting automatic value
validation the same way newvalue(:true) newvalue(:false) does. That
should probably be automatic shouldn't it?
If I leave the newvalues out, and have a manifest like:
macauthorization {"system.device.dvd.setregion.initial":
ensure => present,
shared => false,
}
I get this:
err: //Macauthorization[system.device.dvd.setregion.initial]/shared:
change from true to false failed: Got a nil value for should
hmm. I'll clean up the code a bit and stick it up somewhere to make
this conversation a bit more productive.
>
> The master branch has all of this newvalue code completely refactored,
> and it will be much easier to make it behave more sensibly.
>
> --
> Measure with a micrometer. Mark with chalk. Cut with an axe.
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
--
Nigel Kersten
Systems Administrator
Tech Lead - MacOps
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
