Open Stack

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 <sbadia at redhat.com> 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: 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
> --
> Yanis Guenane
>
>
>
>
> __________________________________________________________________________
> 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