Open Stack

Hunter Haugen <hunter at puppetlabs.com> writes:

>> 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.

I will make a test tomorrow and report back how it goes, but you're
right, it should be ok.

>
>>
>> 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.

That's look like a perfect interface.  I'm going to try this on some
code.  I will report here tomorrow, hopefully in a small review :)

Thanks again for those great insights.

>>
>> 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
>>

-- 
Sofer Athlan-Guyot