Hello, Few weeks ago the patches needed for us to have a cleaner parameters default management way of doing things have been merged [1].
After that each module have been updated so it could rely on this new feature. All but puppet-neutron[3] and puppet-glance[4] have their patch merged. Following on this effort, here is the first review to try to converge to what we expected : https://review.openstack.org/#/c/221005/ Cinder has been picked as the Canary module, if it can make it there it can make it everywhere :) If you have any feedback, please provide them on the review Thank you in advance, [1] https://github.com/openstack/puppet-openstacklib/commit/3b85306d042292713d0fd89fa508e0a0fbf99671 [2] https://review.openstack.org/#/c/209875/ [3] https://review.openstack.org/#/c/209894/ -- Yanis Guenane On 08/06/2015 11:04 AM, Yanis Guenane wrote: > Hi Andrew, > > Sorry for the delay in this answer > > On 07/30/2015 09:20 PM, Andrew Woodward wrote: >> On Thu, Jul 30, 2015 at 3:36 AM Sebastien Badia <[email protected]> wrote: >> >>> On Mon, Jul 27, 2015 at 09:43:28PM (+0000), Andrew Woodward wrote: >>>> Sorry, I forgot to finish this up and send it out. >>>> >>>> #--SNIP-- >>>> def absent_default( >>>> $value, >>>> $default, >>>> $unset_when_default = true, >>>> ){ >>>> if ( $value == $default ) and $unset_when_default { >>>> # I cant think of a way to deal with this in a define so lets pretend >>>> # we can re-use this with multiple providers like we could if this >>> was >>>> # in the actual provider. >>>> >>>> keystone_config {$name: ensure => absent,} >>>> } else { >>>> keystone_config {$name: value = $value,} >>>> } >>>> } >>>> >>>> # Usage: >>>> absent_default{'DEFAULT/foo': default => 'bar', value => $foo } >>> Hi, >>> >>> Hum, but you want to add this definition in all our modules, or directly in >>> openstacklib? >>> >> I only mocked it up in a puppet define, because its easier for me (my ruby >> is terrible) It should be done by adding these kinds of extra providers to >> the inifile provider override that Yanis proposed. >> >> >>> In case of openstacklib, in which manner do you define the >>> <component>_config >>> resource? (eg, generic def, but specialized resource). >>> >>>> #--SNIP-- >>>> >>>> (I threw this together and haven't tried to run it yet, so It might not >>> run >>>> verbatim, I will create a test project with it to show it working) >>>> >>>> So In the long-term we should be able to add some new functionality to >>> the >>>> inifile provider to simply just do this for us. We can add the 'default' >>>> and 'unset_when_default' parameter so that we can use them straight w/o a >>>> wrapping function (but the warping function could be used too). This >>> would >>>> give us the defaults (I have an idea on that too that I will try to put >>>> into the prototype) that should allow us to have something that looks >>> quite >>>> clean, but is highly functional >>>> >>>>> Keystone_config{unset_when_default => true} #probably flatly enabled in >>>> our inifile provider for the module >>>>> keystone_config {'DEFAULT/foo': value => 'bar', default => 'bar'} >>> I'm not sure to see the difference with the Yanis solution here¹, and not >>> sure >>> to see the link between the define resource and the type/provider resource. >>> >> This adds on to Yanis' solution so that we can authoritatively understand >> what the default value is, and how it should be treated (instead of hoping >> some magic word doesn't conflict) > So I think we agree on most points here. '<SERVICE DEFAULT>' value has > been chosen based on our weekly meetings two weeks ago but it remains > customizable (via the ensure_absent_val parameter). > > We need an explicit one by default so it can be set as a default value > in all manifests. > > We mainly picked that value because we thought it was the less likely to > be used as a valid value in any OpenStack related component > configuration file. > > If by any chance it turns out to be a valid value for a parameter, we > can use the temporary fix of changing ensure_absent_val for this > specific parameter and raise the point during a meeting. > > I take the point to make it clear in the README that if a X_config > resource has as a value set to '<SERVICE DEFAULT>' it will ensure absent > on the resource. > > Does that sound good with you ? > >> Seb >>> ¹https://review.openstack.org/#/c/202574/ >>> -- >>> Sebastien Badia >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- > Yanis Guenane > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
