Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150806/7d9db421/attachment.html>