Rejecting unknown fields in metadata

Clint Byrum clint at ubuntu.com
Tue May 15 04:54:35 UTC 2012


Excerpts from Gustavo Niemeyer's message of Mon May 14 14:10:35 -0700 2012:
> On Mon, May 14, 2012 at 5:53 PM, Juan Negron <juan.negron at canonical.com> wrote:
> > +1 from me as well but, I would like to keep Clint's proposal for a
> > maintainer field in metadata.yaml.  As long as we keep the maintainer field,
> > I am ok with rejecting other changes.
> 
> Good point, Juan. Thanks for bringing it up. It should be supported
> and enforced to be in the format we already agreed.
> 
> Other fields may come in the future as well, even if the core doesn't
> make use of them. The idea is just that we "sit down" and talk about
> the meaning and format of these fields so that they are sensible and
> have a unique meaning to everybody.
> 

We absolutely need to enforce a clean composition of charms as much as
makes sense.

I'm not so sure it makes sense for juju to reject all charms that have
unknown fields in metadata.yaml at every level.

As a hypothetical, lets say we do this in version 2.0, with the current
set of keys.

Then we add a 'minimum-version' key which allows us to set the minimum
juju version required, in 4.0.

Somebody writes a new charm, tests it on 2.0, and then decides to set
minimum-version: 2.0 because thats best practice.

Except, 2.0 now rejects minimum-version because it is an unknown key.

I think this calls for warning users about the ignored keys, but not
rejecting. I cannot predict the future, and because of that, I don't
want to sabotage it by having new charms be unnecessarily backward
incompatible.

Adding this check to charm proof (already agreed at UDS) will halt the
flow of any broken new official charms. And we also agreed to start
running charm proof as part of the automated tests, so we'll be alerted
to any that fail this test as soon as an unofficial key is set in an
existing official charm.



More information about the Juju mailing list