Open Stack

Hey Yanis,


On Fri, Jul 17, 2015 at 3:56 AM, Yanis Guenane <yguenane at redhat.com> wrote:

> Hello everyone,
>
> Based on the conversation we had during last meeting I went ahead and
> created an
> ini_setting provider[1] that will act as a proxy between our provider
> and the
> upstream one, this way we don't have to fork, only overload the method
> we want.
>
> The second step towards parameter default management was to provide a
> way that
> means if 'X' is specified as the value for the provider then ensure it
> is absent.
>
> This way we could move from the following pattern :
>
>   if $myvar {
>     keystone_config {'DEFAULT/foo': value => $myvar,
>   } else {
>     keystone_config {'DEFAULT/foo': ensure => absent,
>   }
>
> to a more readable one that would have been
>
>   keystone_config {'DEFAULT/foo': value => $myvar, }
>
> that based on the value of $myvar would have ensure absent the parameter.
>
> In a first time the empty string seemed to have been a good idea, so we
> could
> have default all the parameters to '' (empty string) and live happily
> ever after,
> if set the value would have been set else it would default to upstream
> default.
>
> But Mathieu raised a fair point here[2] is that an empty string for some
> settings is a valid value, and hence we can't rely on
> it.
>
>
Does it make sense for undef to be the 'magic' string for this? As '' or
false may be valid settings, but undef currently is basically ignored (or
so I've been told). Would we want to use undef to indicate the removal of
an option from a configuration?



>
> Since the beginning we are trying to avoid the use of a magic string, but
> I am starting to run out of idea here.
>
> Does someone has an idea on which sane value the default could be ?
>
> Thanks in advance,
>
> [1] https://review.openstack.org/#/c/202488
> [2] https://review.openstack.org/#/c/202574
> --
> 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
>


Thanks,
-Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150717/26c1ba77/attachment.html>