Hunter Haugen <hun...@puppetlabs.com> writes: > I have some code that is similar to this in the F5 and Netscaler > modules. I make a generic "truthy" property that accepts various > truthy/falsy values > (https://github.com/puppetlabs/puppetlabs-netscaler/blob/master/lib/puppet/property/netscaler_ > truthy.rb) then just define that as the parent of the property > (https://github.com/puppetlabs/puppetlabs-netscaler/blob/master/lib/puppet/type/netscaler_ > csvserver.rb#L73-L75)
Ouha! I didn't know that property could have parent class defined. This is nice. Does it work also for parameter ? The NetScalerTruthy is more or less what would be needed for thruthy stuff. On my side I came up with this solution (for different stuff, but the same principle could be used here as well): https://review.openstack.org/#/c/238954/10/lib/puppet_x/keystone/type/read_only.rb And I call it like that: newproperty(:id) do include PuppetX::Keystone::Type::ReadOnly end I was thinking of extending this scheme to have needed types (Boolean, ...): newproperty(:truth) do include PuppetX::Openstack::Type::Boolean end Your solution in NetScalerTruthy is nice, integrated with puppet, but require a function call. My "solution" require no function call unless you have to pass parameters. If you have to pass parameter, the interface I used is a preset function. Here is an example: https://review.openstack.org/#/c/239434/8/lib/puppet_x/keystone/type/required.rb and you use it like this: newparam(:type) do isnamevar def required_custom_message 'Not specifying type parameter in Keystone_endpoint is a bug. ' \ 'See bug https://bugs.launchpad.net/puppet-keystone/+bug/1506996 ' \ "and https://review.openstack.org/#/c/238954/ for more information.\n" end include PuppetX::Keystone::Type::Required end So, modulo you can have parameter with parent, both solutions could be used. Which one will it be: - one solution (NetScalerTruthy) is based on inheritance, mine on composition. - you have a function call to make with NetScalerTruthy no matter what; - you have to define function to pass parameter with my solution (but that shouldn't be required very often) I tend to prefer my resulting syntax, but that's really me ... I may be biased. What do you think ? > > On Mon, Nov 2, 2015 at 12:06 PM Cody Herriges <c...@puppetlabs.com> > wrote: > > Sofer Athlan-Guyot wrote: > > Hi, > > > > The idea would be to have some of the types defined oslo config > > > > http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/types. > py > > ported to puppet type. Those that looks like good candidates > are: > > - Boolean; > > - IPAddress; > > and in a lesser extend: > > - Integer; > > - Float; > > > > For instance in puppet type requiring a Boolean, we may test > > "/[tT]rue|[fF]alse/", but the real thing is : > > > > TRUE_VALUES = ['true', '1', 'on', 'yes'] > > FALSE_VALUES = ['false', '0', 'off', 'no'] > > > > Good idea. I'd only add that we should convert 'true' and 'false' > to > real booleans for Puppet's purposes since the Puppet language is > now typed. > > -- > Cody > > ___________________________________________________________________ > _______ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sofer Athlan-Guyot __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev