Nan
Cheers again for the info...
Now I think more about it, you may well be right in that it should be part
of the netapp_volume provider...
However I'm not sure that having individual params/properties for each
volume option is the right way - The list of possible volume options
currently stands at 36.. I don't really fancy having to implement a
param/property for each of those... However I could see a single 'options'
hash param/prop working for that... Although then I'm back to the same
challenge of making sure each volume option is set & maintained
correctly...
The other challenge is that to set volume options is a different webservice
call to the volume-list/volume-create method, but I'm guessing I can just
get that handled with another def in the provider...
Thoughts?
Cheers
Gav
On 14 November 2012 17:29, Nan Liu <n...@puppetlabs.com> wrote:
> On Wed, Nov 14, 2012 at 8:56 AM, Gavin Williams <fatmc...@gmail.com>wrote:
>
>> Cheers for the response... Looks like I've got some more reading to do to
>> get my head around some of the more complex stuff...
>>
>
> I'm not sure why netapp_volume_options is a separate resource. You are
> already managing the volume state in netapp_volume, and all netapp volume
> options should be properties in netapp_volume instead.
>
> Think you're right in that I'm trying to treat the options as a whole,
>> rather than individual items...
>>
>
> The resource seems to make more sense modeled as:
>
> netapp_volume { 'example':
> ensure => present,
> initsize => '2GB',
> convert_ucode => 'on',
> no_atime_update => 'on',
> }
>
> The provider exists? method should simply return true if the volume is
> present and it should not compare the property values (that's what Puppet
> does for you). One key difference is volume options should be newproperty.
> So far you implemented all attributes as parameters, and puppet will not
> retrieve and compare parameter values (i.e. it will not call
> initsize/initsize= method).
>
> The convert_ucode method return the option value. and convert_ucode=
> method updates the setting.
>
>
>> Am I better off moving to a prefetch/flush style provider, rather than
>> the getter/setting method?
>>
>
> I would avoid prefetch/flush until you have the provider working with
> individual get/set first.
>
> Thanks,
>
> Nan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
