charm config default values are broken

[Thomi Richards]

There are two (probably) related issue here.

Given a charm with a config.yaml that contains:

```
options:
    option_name:
        type: string
        default:
        description: "some description"
```

I expect the following:

 1) when reading the config in the charm, the default value should be the empty string.
 2) When displaying the config in the CLI with 'juju config <service_name>' the value should be displayed as '' or "" (assuming I haven't set a config value yet).

What actually happens:

 1) The charm gets 'None' as the value, which is odd, since I've explicitly said that the config type should be 'string'.
 2) the 'juju config' command shows:

```
settings:
  option_name:
    default: true
    type: string
    description: "some description"
```

...which makes no sense at all. Where does 'true' come from?

[Anastasia (anastasia-macmood)]

I agree that the output is confusing (especially with respect to the input, i.e. metadata.yaml meanings). However, this was always the case.

"default" in the output is a boolean as it's an indication that the value is the same as the charm's default value.

The "none" value requires a bit more explaining. Essentially, when you did not specify a value, you wanted it to be 'nil'. However, internally nil values have special meaning. To differentiate between a special meaning and the fact that user actually wanted a nil value, we use 'None'. If you wanted an empty value, for string type settings, please specify empty string ("" or equivalent).

[Thomi Richards (thomir-deactivatedaccount)]

Hi Anastasia,

Regarding the 'default' output, I really think this UX needs to be changed - here's why:

It is a reasonable expectation that 'juju config' should show what has been specified in config.yaml. Currently both config.yaml and 'juju config' output use the 'default' key, but they have very different semantic meanings:

 * 'default' as in 'this is the default value to use, if none is set' (from config.yaml).
 * 'default' as in 'the current value is the default' (from 'juju config')

It's really confusing to have this key reused in two closely related pieces of UX but have very different meanings. I suggest changing the CLI UX so 'default' becomes 'is_default' or similar.

Regarding the 'juju config' output generally, the current behaviour means that it's impossible to see what config value is present if we're still using the charm default. Shouldn't it be possible to see these default values in the 'juju config' output?

[Thomi Richards (thomir-deactivatedaccount)]

I just ran into another example this morning, and realised that this is even more confusing when the config is a boolean type. For example:

```
  cassandra_enabled:
    default: true
    description: Should we connect to the cassandra cluster?
    type: boolean
    value: false
```

This may seem obvious to juju developers, but to me (and, I suspect many others) this reads as "the default value is true, the current value is false", which is incorrect.

[Anastasia (anastasia-macmood)]

@Thomi Richards (thomir),

I completely agree with you - we should either have 'is_default' to indicate that the unit value is the the same as charm value... Or my personal preference is to have "charm_value" and "unit_value" fields. I think that this will be clearer what values are used, declared, etc.

What do you think?
So your example above would be :

```
  cassandra_enabled:
    description: Should we connect to the cassandra cluster?
    type: boolean
    charm_value: false
    unit_value: false
```

or, if application was deployed different value:

```
  cassandra_enabled:
    description: Should we connect to the cassandra cluster?
    type: boolean
    charm_value: false
    unit_value: true
```

[Thomi Richards (thomir-deactivatedaccount)]

Hi Anastasia,

I find the 'charm_value' / 'unit_value' terminology to be potentially confusing. From an operational point of view, the thing I care most about is what value is effective for the service right now. Put another way: once I've set a value, most of the time I don't care what the old default value was (However, see below). I think listing both the default value and the current value is going to be noise in most cases.

The one scenario where I think it's useful to know what the charm default value was is when you're in a situation where something's broken, and you just want to un-set whatever you just changed. Even then, I'm not convinced you need to know what the default value is - if juju had some way to "un-set this config option" then that would probably be enough.

So, my preference for UX here would be this:

```
  cassandra_enabled:
    description: Should we connect to the cassandra cluster?
    type: boolean
    value: false
```

(i.e.- not showing 'default' at all).

My second preference would be this:

```
  cassandra_enabled:
    is_default: true
    description: Should we connect to the cassandra cluster?
    type: boolean
    value: false
```

(i.e.- just renaming 'default' to 'is_default').

If there's a requirement to show what the charm says the default value is, I'd suggest this:

```
  cassandra_enabled:
    default_value: false
    description: Should we connect to the cassandra cluster?
    type: boolean
    value: false
```

Cheers,

[Thomi Richards (thomir-deactivatedaccount)]

Oh, and while we're at it, it'd be super nice if the output could order the description, type, value, etc keys in a consistent and logical order.

I'm aware that the order of items in a yaml mapping makes no logical difference, but it'd still be nicer UX if these were ordered in a sensible manner.

[Anastasia (anastasia-macmood)]

To unset application config values, use 'juju config --reset' (see 'juju help config'). This command with a reset flag will revert comma-delimited list of config to charm default values.

[John A Meinel (jameinel)]

Isn't the ordering is alphabetical order?

On Tue, Jun 20, 2017 at 10:00 AM, Anastasia <<email address hidden>
> wrote:

> To unset application config values, use 'juju config --reset' (see 'juju
> help config'). This command with a reset flag will revert comma-
> delimited list of config to charm default values.
>
>
> ** Changed in: juju
> Status: Incomplete => Triaged
>
> ** Changed in: juju
> Importance: Undecided => Medium
>
> ** Tags added: usability
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1697837
>
> Title:
> charm config default values are broken
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1697837/+subscriptions
>

[Anastasia (anastasia-macmood)]

A dedicated report was filed that will deal with default/is_default part of this report - bug # 1709692.

[Anastasia (anastasia-macmood)]

I am marking this a duplicate of bug # 1709692 since it is dedicated to default vs is_default and I have added a PR reference to it.

For the ability to see default option, there is another dedicate bug, bug # 1709694.