Stefan

Cheers for the response. Makes sense to me, am happy to leave it like it is
: )

Cheers
Gavin


On 2 July 2013 18:38, Stefan Schulte <notifications@github.com> wrote:

> In lib/puppet/type/netapp_quota.rb:
>
> > +          normalized <<= UNIT_BASE[unit]
> > +        end
> > +        normalized
> > +      else
> > +        raise Puppet::Error, "#{value} is not a valid size"
> > +      end
> > +    end
> > +  end
> > +
> > +  newparam(:name) do
> > +    desc "The name of the quota target.  Depending on the quota type this
> > +      can be a pathname (e.g. `/vol/vol1/qtree1`), a username, or a group"
> > +    isnamevar
> > +  end
> > +
> > +  newproperty(:qtree) do
>
> I think you can argue about that, so here is my view ;-)
>
> A parameter in general is just a way to tell the type or provider how to
> behave in different situations. For the netapp_quota type I can image a resize
> => true/false parameter to surpress quota reloading/resizing after
> changing a quota entry (for performance reasons or whatever). This would
> just tell the provider what to do after changing an entry but it is not
> something that has a "current value" and a "desired value".
>
> When you look at the following quota entry:
>
> bob user@/vol/home/bob_h 100M 10K 90M 90M 9K
>
> and the following resource
>
> netapp_quota { 'bob':
>   ensure    => present,
>   type      => user,
>   volume    => 'home'
>   qtree     => 'some_other_tree',
>   disklimit => '200M',
> }
>
> then - in an ideal world - name, type, volume and qtree should all be
> parameters because they tell the provider against which existing
> quota_entry you want your resources to match against. In the NetApp-World
> the puppetresource above describes a *different* quota entry than the
> line above (one quota entry is identified by target, type, volume and
> qtree). Unfortunelty multiple keyattributes are broken in Puppet so we have
> to treat the quota entry and the resource as identical (because the
> quota-target is everything that counts)
>
> So if we life with the fact that quota-target has to be unique then I'd
> say that qtree should be treated as a property because it has a current
> value and a desired value. But we have a problem if qtree is out of sync:
> We'd have to remove and recreate the quota (remeber: in the NetApp world
> two quotas with the same target but different qtrees are two different
> quotas). I just did not want to implement that and prefer to raise a
> warning.
>
> If we implement qtree as a parameter, we may run in situations where a
> resource declaring to operate on qtree q1 modifies the disklimit of qtree
> q2 without raising any warnings. This may lead to a few surprises ;-)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/fatmcgav/fatmcgav-netapp/pull/41/files#r4990615>
> .
>