Open Stack

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