how to allow user specified property names in provider code

13 views
Skip to first unread message

Philip Brown

unread,
May 3, 2012, 9:18:15 PM5/3/12
to puppe...@googlegroups.com
Hi folks,

I'm trying to write a new provider, to set SMF properties, and I need help on a piece of puppet internals syntax.
I understand(?) that generally speaking when a resource has a KNOWN set of property names, for example, "quota" and "readonly", all you have to do to properly handle that sort of thing is,

def quota
  (return value of quota)
end
def quota=
  (set quota to be equal to :name value)
end

However, I'm trying to write a provider, where the property names are free-form.
From the end user point of view, usage should look something like

###site.pp
node somenode{
  mynewtype { 'svc:/top/level/holder':
      property => 'funky_holder_switch',
      value => 'blue_switch'
  }
}
#####

The name of the value in "property" is completely unknown to me at time of writing the provider code. it could be literally anything the user chooses.

How can I handle that?


For the curious, I already figure that the end result, will be a command line that looks like
svccfg("-s", @resource[:name],"setprop", @resource[:property],"=", :value)


I know how to do that backend part. and I've written the front end 'type' definition.  I'm just missing the trick of finding the middle layer glue to connect the two together :-}


Chris Price

unread,
May 4, 2012, 4:42:35 PM5/4/12
to puppe...@googlegroups.com
I'm not an expert on the topic, but my understanding is that you can't create a type without well-defined property/parameter names.  Or, to put it a different way, there is currently no officially sanctioned means by which to support dynamic property/parameter names for a type or a provider.

One way that you could work around it is to define a property with a name like "options", whose value would be a hash.  Then there are no restrictions on your hash key names.

There is some discussion around this topic on the following tickets:


You can see an example use of this pattern via the "install_options" parameter in the following type/provider pair:


Note, however, that this is not generally considered to be an ideal solution to this sort of problem; I believe we are still honing in on the best long-term solution for this, so I'm not necessarily recommending this hash-based approach... but just thought I'd point it out in case it helps you get unstuck for now.





--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-dev/-/JBpEd0SYmoMJ.
To post to this group, send email to puppe...@googlegroups.com.
To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.

Philip Brown

unread,
May 4, 2012, 5:19:51 PM5/4/12
to puppe...@googlegroups.com


On Friday, May 4, 2012 1:42:35 PM UTC-7, Chris Price wrote:
I'm not an expert on the topic, but my understanding is that you can't create a type without well-defined property/parameter names.  Or, to put it a different way, there is currently no officially sanctioned means by which to support dynamic property/parameter names for a type or a provider.

One way that you could work around it is to define a property with a name like "options", whose value would be a hash.  Then there are no restrictions on your hash key names.

There is some discussion around this topic on the following tickets:



Thanks for the reply.

It looks like I'll just have to hack around things by forcing checks in exists?, along the lines of
    if ! defined?(@resource[:property])
      raise ArgumentError, "sysprop requires 'property' to be defined"


Except that... that doesnt seem to be working as-is. Guess I need to use a different conditional.

Luke Kanies

unread,
May 5, 2012, 9:28:25 PM5/5/12
to puppe...@googlegroups.com
On May 4, 2012, at 2:19 PM, Philip Brown wrote:


On Friday, May 4, 2012 1:42:35 PM UTC-7, Chris Price wrote:
I'm not an expert on the topic, but my understanding is that you can't create a type without well-defined property/parameter names.  Or, to put it a different way, there is currently no officially sanctioned means by which to support dynamic property/parameter names for a type or a provider.

You are correct that resource types need well-defined names.  We've explored alternatives, but it's hard to have a model without defining it specifically somewhere.

There are some weird things you can do with defined resources that obscure this problem sometimes, but… I can't recommend even figuring out what they are, as I have a scar there in my brain from doing so at one point.

One way that you could work around it is to define a property with a name like "options", whose value would be a hash.  Then there are no restrictions on your hash key names.

There is some discussion around this topic on the following tickets:



Thanks for the reply.

It looks like I'll just have to hack around things by forcing checks in exists?, along the lines of
    if ! defined?(@resource[:property])
      raise ArgumentError, "sysprop requires 'property' to be defined"


Except that... that doesnt seem to be working as-is. Guess I need to use a different conditional.

defined? probably doesn't work very well when checking hash values.  I recommend 'nil?' or something similar:

@resource[:property].nil?

Reply all
Reply to author
Forward
0 new messages