config: empty strings return null with --format=json

[James Page]

Example config.yaml for a charm:

options:
  database:
    default: ""
    type: string
    description: empty string
  test_two:
    type: string
    description: no default string

Retrieving these values without setting config:

config-get --format=json database
null
config-get --format=json test_two
null

This is a behavioral change from python juju where the following would happen:

config-get --format=json database
""
config-get --format=json test_two
null

I hit this while testing out some proposed changes to the postgresql charm on juju-core; parsing 'null' results in None in python - parsing "" results in an empty string = #BANG!

[James Page (james-page)]

Oh - I'm using juju-core built from trunk locally as of today.

[Frank Mueller (themue)]

Hi James,

we discussed this topic and came to a semantic problem deeper in the configuration. While the default value in config.yaml allows an empty string as valid value this cannot be set by the command line. Here an empty value has the semantics of deleting/unsetting this option. This is inconsistent. So currently in gojuju the configuration logic handles empty value generally as unset. Reading it with config-get only shows this.

While empty strings as values are surely a convenient feature this also can be handled by interpreting null as "this option is not set". So some of as would like to deprecate the old behavior of pyjuju and keep it in gojuju as it is right now. This way the system stays consistent and comprehensible.

Others instead say we add an exception only for the default value. In that case the behavior is compatible between pyjuju and gojuju, but inconsistent.

What do you say? And do we have an overview on how many charms use empty strings as default values?

mue

[James Page (james-page)]

Frank

I've posted a summary of this bug to the Juju list; I'd like to a) raise awareness and b) get charm authors to check their charms.

I personally prefer this behavior; but the potential impact is high.

Cheers

James

[David Britton (dpb)]

Apache2 and postgresql in the charm store are affected by this change. Both get into a traceback situation where the presence of the key makes them think they can read it as a string (which they could in pyjuju), but it comes back None.

My personal vote is to maintain strict backward compatibility with config-get and relation-get behavior from pyjuju.

[David Britton (dpb)]

I linked a related branch that solves the problem for me, with test fixes. I get some other failures in the tests, but they seem unrelated (like needing a particular juju environments.yaml file).

[Frank Mueller (themue)]

Hi David,

thx for your branch. Will take this issue again and propose a fixed keeping your branch in mind.

mue