Removing strict type-validation for string/int type configuration options (None is good!)

Stuart Bishop stuart.bishop at canonical.com
Tue Feb 11 05:38:45 UTC 2014


On 10 February 2014 21:49, Marco Ceppi <marco.ceppi at canonical.com> wrote:
> Hi all,
>
> Currently, one of the proof requirements within charm-tools is that all
> configuration options must have a default key with a matching type value for
> that key.
>
> Most notably, some charms omit the default key and use strict None/NULL
> checking within the charm.
>
> In order to statisfy this proof rule, which is currently a WARNING level
> (meaning it does not interrupt juju operation, but can affect tools within
> the ecosystem), we've taken to adding `default: ""` to these missing keys.
> The reason being we had no way previously to set a None/NULL type value via
> the command line.
>
> Given that we now have the ability to do so via `juju unset` I'd like to
> propose we drop the requirement of having strict type checking and allow
> None/NULL as a valid configuration default for both string and int types
> (but not bool). In doing so we will still require you have a default: key
> present but it set to an appropriate value of either a value of the type the
> configuration is OR None/NULL[0]
>
> A WARNING will still be raised if no default key is present or if the
> default key is not the type the configuration option expects (and in the
> case of string or int, also not NULL/None)
>
> Looking for some +1's or feedback on this policy change, hoping to get it
> released in the next version of charm-tools.

I've already got some 'default: null' items, so +1.

We need to clarify things though. You are talking about None/null, but
the current behavior is that setting 'default: null' means the item is
unset, and 'juju unset' also unsets the key rather than sets it to a
null value. This is a pedantic detail, but dictates if the correct
behavior of "config-get typoo" is to return null or raise an error
(and similarly, relation-get typoo when typoo had not previously been
explicitly set or unset).

Making this change from 'default: ""' caused a few minor hiccups, in
that previously config('myitem') == "", but after the change
config('myitem') raised a KeyError. charm-helpers needs a minor
update, as at the moment relation_set('foo', None) sets foo to the
empty string, and instead should unset the key. And should
"relation_set('foo', None); relation_get('foo')"  return None or raise
a KeyError?

-- 
Stuart Bishop <stuart.bishop at canonical.com>



More information about the Juju mailing list