Firstly, sorry for bringing this thread back - However I thought it
probably best as it's got all the history of what I was working towards
etc...
Anyways, onto the problem at hand.
I've created a new property against my netapp_volume provider called *
:snapschedule*.
This property is taking
John,
Again, very helpful...
My knowledge of puppet is growing every day thanks to posts like this :-)
Cheers
Gavin
On Nov 26, 2012 7:30 PM, "jcbollinger" wrote:
>
>
> On Monday, November 26, 2012 12:19:09 PM UTC-6, Gavin Williams wrote:
>>
>> John
>>
>> Cheers again, that could be a good alter
On Monday, November 26, 2012 12:19:09 PM UTC-6, Gavin Williams wrote:
>
> John
>
> Cheers again, that could be a good alternative way of doing it... Use
> insync? just to trigger options=, and then work out what actually needs
> setting there...
>
That's not just a good alternative, it's the
John
Cheers again, that could be a good alternative way of doing it... Use
insync? just to trigger options=, and then work out what actually needs
setting there...
Cheers
Gav
On Nov 26, 2012 5:42 PM, "jcbollinger" wrote:
>
>
> On Friday, November 16, 2012 5:44:09 AM UTC-6, Gavin Williams wrote:
On Friday, November 16, 2012 5:44:09 AM UTC-6, Gavin Williams wrote:
>
> However still looks like if one of the *:options *doesn't match, then the
> whole lot gets set again... I guess that's a reasonable logic in that if
> one doesn't match, it's quite possible other's don't match, so set them
On 11/13/2012 08:19 PM, Gavin Williams wrote:
> After a quick google, came up with:
>
> #!/usr/bin/env ruby
>
> grades = { "Bob" => 82,
>"Jim" => 94,
>"Billy" => 58
> }
>
> grades.each do|name,grade|
> puts "#{name}: #{grade}"
>
Ok, think I've kinda answered my own question...
Added some additional logging to *insync?*, and spotted a flaw in my *
'options'* logic. I was stripping matching values at that level, rather
than letting *insync *take care of that.
So tweaked the *option* as follows:
--- a/lib/puppet/provide
Ok, after a considerable amount of reading, and some expermentation, I
think I've got a working netapp_volume type/provider which can handle
setting volume options! :D
Have branched the code to play with, so it's available here:
https://github.com/fatmcgav/fatmcgav-netapp/tree/volume_options_te
On Wed, Nov 14, 2012 at 9:44 AM, fatmcgav wrote:
> 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
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 stand
On Wed, Nov 14, 2012 at 8:56 AM, Gavin Williams 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
John
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...
Think you're right in that I'm trying to treat the options as a whole,
rather than individual items...
Am I better off moving to a prefetch/flush style provider
On Wednesday, November 14, 2012 6:04:11 AM UTC-6, Gavin Williams wrote:
>
> Ok, I've just pushed the latest code to Github:
> https://github.com/fatmcgav/fatmcgav-netapp/commit/d5ae999fc49b1de6726e8f4b7027648cf2eb64a2
>
> I've managed to get the *create *functioning correctly, and updating the
Ok, I've just pushed the latest code to Github:
https://github.com/fatmcgav/fatmcgav-netapp/commit/d5ae999fc49b1de6726e8f4b7027648cf2eb64a2
I've managed to get the *create *functioning correctly, and updating the
NetApp options as required.
*exists?* has also been fleshed out a lot.
Logic is
On Tue, Nov 13, 2012 at 11:58 AM, fatmcgav wrote:
> Looks like overriding the 'insync?' method is the way to go, as I'm only
> interested in checking/setting property values that are being passed
> through...
>
> Any insync? examples that I could refer to?
>
There's a simple example here:
https:
Nan
Cheers again...
Looks like overriding the 'insync?' method is the way to go, as I'm only
interested in checking/setting property values that are being passed
through...
Any insync? examples that I could refer to?
Cheers
Gavin
On 13 November 2012 19:50, Nan Liu wrote:
> On Tue, Nov 13, 2
On Tue, Nov 13, 2012 at 11:19 AM, Gavin Williams wrote:
> After a quick google, came up with:
>
> #!/usr/bin/env ruby
>>
>> grades = { "Bob" => 82,
>>"Jim" => 94,
>>"Billy" => 58
>> }
>>
>> grades.each do|name,grade|
>> puts "#{name}: #{grade}"
>> end
>
>
> So n
After a quick google, came up with:
#!/usr/bin/env ruby
>
> grades = { "Bob" => 82,
>"Jim" => 94,
>"Billy" => 58
> }
>
> grades.each do|name,grade|
> puts "#{name}: #{grade}"
> end
So now all I need to do is pull the existing options values and compile a
hash
Nan
Cheers for the response.
Yes this is just a parameter...
What's the easiest way to work with them in the provider?
Cheers
Gavin
On Nov 13, 2012 7:00 PM, "Nan Liu" wrote:
> On Tue, Nov 13, 2012 at 7:33 AM, fatmcgav wrote:
>
>> One of the functions required is the ability to set 'options'
On Tue, Nov 13, 2012 at 7:33 AM, fatmcgav wrote:
> One of the functions required is the ability to set 'options' against a
> given volume.
> What I want to do is create a provider that accepts a volume name and a
> list of volume options with their corresponding settings, and then iterate
> throu
John
Cheers for the response.
As per my other threads, I'm writing a NetApp Network device module for
Puppet.
One of the functions required is the ability to set 'options' against a
given volume.
What I want to do is create a provider that accepts a volume name and a
list of volume options with
On Tuesday, November 13, 2012 8:47:00 AM UTC-6, Gavin Williams wrote:
>
> Afternoon all
>
> Is it possible to pass an array of key=value pairs to a provider param,
> and have the provider split and handle each key=value pair?
>
> Basically, I've defined a new provider and type as follows:
> ht
22 matches
Mail list logo
