Open Stack

> Ouha!  I didn't know that property could have parent class defined.
> This is nice.  Does it work also for parameter ?

I haven't tried, but property is just a subclass of parameter so
truthy could probably be made a parameter then become a parent of
either a property or a 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.

The function call is to a) pass documentation inline (since I assume
every attribute has different documentation so didn't want to hardcode
it in the truthy class), and b) pass the default truthy/falsy values
that should be exposed to the provider (ie, allow you to cast all
truthy values to `"enable"` and `"disable"` instead of only supporting
`true` and `false`.

The truthy class could obviously be implemented such that if no block
is passed to the attribute then the method is automatically called
with default values, then you wouldn't even need the `include` mixin.
>
> 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 <cody at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 


-Hunter