[openstack-dev] [puppet] Removing old puppetlabs/* forge OS modules

[Hunter Haugen]

Several years ago, the at-the-time Stackforge puppet modules were published
under the forge.puppetlabs.com/puppetlabs namespace. Then those modules
were migrated to forge.puppetlabs.com/stackforge for a while. When they
became an official OpenStack project they were migrated to
forge.puppetlabs.com/openstack where they are currently being published.

After each migration, the older releases were left available for anyone who
needed to continue using them before migrating. Now, the older versions
generally just cause confusion among new users, so I am going to remove the
following modules from the forge on March 8th:

* https://forge.puppetlabs.com/puppetlabs/keystone
* https://forge.puppetlabs.com/puppetlabs/glance
* https://forge.puppetlabs.com/puppetlabs/cinder
* https://forge.puppetlabs.com/puppetlabs/horizon
* https://forge.puppetlabs.com/puppetlabs/swift
* https://forge.puppetlabs.com/puppetlabs/ceilometer
* https://forge.puppetlabs.com/puppetlabs/heat
* https://forge.puppetlabs.com/puppetlabs/tempest
* https://forge.puppetlabs.com/puppetlabs/nova
* https://forge.puppetlabs.com/puppetlabs/vswitch
* https://forge.puppetlabs.com/puppetlabs/neutron
* https://forge.puppetlabs.com/puppetlabs/quantum

And as a bonus for related-but-no-longer-relevant modules:

* https://forge.puppetlabs.com/puppetlabs/grizzly
* https://forge.puppetlabs.com/puppetlabs/havana


-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] Push Mitaka beta tag

[Hunter Haugen]

-Hunter

On Tue, Feb 16, 2016 at 11:44 AM, David Moreau Simard <d...@redhat.com>
wrote:

> On Tue, Feb 16, 2016 at 2:18 PM, Hunter Haugen <hun...@puppetlabs.com>
> wrote:
> > The forge does verify that versions match semver 1.0.0, which states "a
> > pre-release version number MAY be denoted by appending an arbitrary
> string
> > immediately following the patch version and a dash. The string MUST be
> > comprised of only alphanumerics plus dash [0-9A-Za-z-]" thus this tag
> would
> > more appropriately be 8.0.0-beta1 (as per the given example on
> > http://semver.org/spec/v1.0.0.html).
> >
> > The forge doesn't care about tags, but if you have 8.0.0b1 in the
> metadata
> > it will probably deny the publish.
>
> Can we double check if that is indeed the case ?
> I feel it's important to keep the same version format as the rest of
> OpenStack.
>

 ae% grep version metadata.json
  "version": "8.0.0b1",
ae% puppet module build
Error: Invalid 'version' field in metadata.json: version string cannot be
parsed as a valid Semantic Version
Error: Try 'puppet help module build' for usage

So OpenStack doesn't follow semver? Afaik 8.0.0b1 doesn't even follow
semver 2 http://semver.org/#spec-item-9


> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
> __
> 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.

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

[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