Re: [openstack-dev] [puppet] Match type checking from oslo.config.

[Sofer Athlan-Guyot]

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

Re: [openstack-dev] [puppet] Match type checking from oslo.config.

[Hunter Haugen]

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


-- 


-Hunter

__
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

Re: [openstack-dev] [puppet] Match type checking from oslo.config.

[Sofer Athlan-Guyot]

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

Re: [openstack-dev] [puppet] Match type checking from oslo.config.

[Hunter Haugen]

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
)

On Mon, Nov 2, 2015 at 12:06 PM Cody Herriges  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

Re: [openstack-dev] [puppet] Match type checking from oslo.config.

[Cody Herriges]

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



signature.asc
Description: OpenPGP digital signature
__
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-dev] [puppet] Match type checking from oslo.config.

[Sofer Athlan-Guyot]

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

all this being case insensitive.

This can lead to discrepancies when checking if the resource is in_sync
for instance, as it could be saved as "1" and we would check for "true".

IPAddress could/should be use in puppet-neutron for instance to catch
problems earlier.

Eventually, this would be a library of types that could be included,
using a mixin in any type/provider and that would define the:
 - is_sync;
 - validate;
 - newparam;

Something like:

  newproperty(:gateway_ip) do
include Puppet_X::Openstack::Types::IPAdrress
  end

Float and Integer are very easy to make and I put them for completeness.

Any other types could be included there as well.

This point was raised during the last meeting[1] 

[1] 
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-13-15.00.html
-- 
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