juju-core; default configuration value of ""

Sat Jun 22 15:51:13 UTC 2013

My basic theory on these kind of "backwards compatibility" issues is: If
there we are breaking people's stuff, we should try to be
backwards compatible. If we are doing something that incurs "technical
debt" to do so, we should warn people that we are making a change, but then
we should feel free to (in 2.2) remove the old way.

This system has been used pretty effectively by the Python language and
which has deprecated a lot of stuff over many releases.  And it worked a
lot better for than the Python 3.0 way of just changing stuff under
people's feet -- so to the extent it is possible I am definitely for the
"accomodate then deprecate  strategy wherever reasonably possible.

And I think we will find that there are things we are doing now that we
will want to deprecate in 2.2 so we can fix them in 2.4.  I do't think this
is just a python to go issue, it's just what you have to do to evolve a
platform in a ordered way.

--Mark Ramm

On Sat, Jun 22, 2013 at 9:52 AM, William Reade
<william.reade at canonical.com>wrote:

> David, your bug is definitely real, and the fix for it is just waiting for
> a final review. Sorry, and thanks for catching it.
>
> James, yours is more involved. We had originally considered empty string
> values to be "impossible" on the basis that, whether set via key=value or
> --config with a YAML file, they were interpreted internally as "delete this
> key". On this basis, I'm not sure we even explicitly tested for an empty
> string default...but we let it through, and now it's a feature.
>
> And, ofc, it's clear that it's not reasonable for us to snatch this
> feature away suddenly. So we'll gladly fix it now; but this leaves us in a
> slightly uncomfortable position, in which there's a value that's only
> settable as a default, and that feels like a misfeature at best. So, long
> term, we could deprecate *all* uses of ""; or we could try to find some way
> to make it UI- and API-settable; or, possibly, we could grandfather it in
> as a permanent exception.
>
> I'm not very keen on the second option, because I think that
> `""-means-delete` is a simple rule that everybody already understands at
> the UI level, and I'm not keen to introduce special syntax to the CLI to
> allow specification of two different sorts of empty strings (one of which
> means delete); if there's overwhelming support for it we can of course
> accommodate that, but probably not on a helpful timescale.
>
> So, right now, we can temporarily fix and deprecate, or permanently
> grandfather it in. The only difference today is whether or not we print a
> deprecation warning when we encounter it; but it's informed by the bigger
> question of whether we ultimately want to exclude "", or to integrate it
> properly.
>
> (FWIW, independent of convenience at the code level, I think there's a
> real case to be made that the "language" defined by a config file should be
> as high-level and human-focused as possible; an interface that doesn't
> require that end-users understand the distinction between null and an empty
> string would STM to win, in general, over one that does. Hence, my personal
> preference is currently for deprecation.)
>
> Cheers
> William
>
> PS in case it's unclear: we're fixing it now, regardless, and we won't
> block that on the outcome of this discussion.
>
>
> On Fri, Jun 21, 2013 at 8:38 PM, Stuart Bishop <
> stuart.bishop at canonical.com> wrote:
>
>> On Sat, Jun 22, 2013 at 12:56 AM, James Page <james.page at ubuntu.com>
>> wrote:
>>
>> > A couple of days ago I noticed a change in behaviour for default string
>> > configuration values of "" in juju-core when compared to pyjuju.
>> >
>> > Example config:
>> >
>> > options:
>> >   database:
>> >     default: ""
>> >     type: string
>> >     description: empty string
>> >   test_two:
>> >     type: string
>> >     description: no default string
>> >
>> > Under pyjuju:
>> >
>> > config-get --format=json database
>> > ""
>> > config-get --format=json test_two
>> > null
>> >
>> > Under juju-core:
>> >
>> > config-get --format=json database
>> > null
>> > config-get --format=json test_two
>> > null
>> >
>> > Specifically this breaks the postgresql charm on juju-core; I've raised
>> a
>> > bug (see [0]) to which the juju-core team have responded; I prefer the
>> > proposed new behaviour (its in effect what I do in the charmn helpers I
>> have
>> > written) but I appreciate that this will probably have impact on a large
>> > number of charms; so I'd like to throw this open to the list for further
>> > discussion.
>> >
>> > Thoughts?
>>
>> (after reading bug comments too)
>>
>> It would be possible to set null via the command line if relation-set
>> accepted json or yaml. We could even get real structured data in there
>> instead of all this v.split() rubbish and pickles being shuffled
>> around.
>>
>> I suspect the charms that are complex enough to worry about null vs ''
>> are going to need updating for gojuju in any case.
>>
>> If you are breaking compatibility, you might consider something like
>> "relation-set key=val -key2 key3=", where key2 ends up with null and
>> key3 ends up with the empty string. If '' and null are pretty much
>> interchangable with pyjuju it might not be as invasive as it looks.
>>
>> --
>> Stuart Bishop <stuart.bishop at canonical.com>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130622/d9a052bc/attachment.html>