Rejecting unknown fields in metadata

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of Tue May 15 12:38:14 -0700 2012:
> On Tue, May 15, 2012 at 1:54 AM, Clint Byrum <clint at ubuntu.com> wrote:
> > 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.
> 
> You're right, and I'm happy to relax a bit the constraints on
> deployment for the reason you point out, as I'm probably being
> over-strict on the way to educating people that the metadata file is a
> reserved namespace.
> 
> Note that the example you provide is not a good one, though. Think
> about what would happen with version 2.0 when it sees a
> minimum-version: 4.0 (nothing, and breaks silently).
> 

Agreed, after sending I was thinking that it was probably a confluence of
two ideas, and not a great way to illustrate the point.

A better example would be a 'tags:' or 'category:' key that would only
be used by the charm store. We might go back and re-tag everything,
but that wouldn't mean we went back and broke it.

> Perhaps Kapil is right then, and we should introduce such a
> "minimum-version" (or "juju-version"?) field now, so that we can make
> such statements in the future.
> 

Agreed, this exercise has convinced me of that as well. Having a
minimum-version now means we can start pushing charm features confidently
as soon as we want to.

This is also good since we can keep track of truly incompatible keys
as they pertain to the minimum version. So if in v6.0 we add storage
capabilities that might break previous versions, we can at least have
6.0 reject a charm that says minimum-version: 4.0 but then uses the
storage keys.

> Kapil, in case you decide to go ahead with this, what do you think of
> the following semantics:
> 
> - Field format: juju-version: ([0-9]+)(\.[0-9]+)?(\.[0-9]+)?
> - Semantics:
>     - 2 is equal to 2.0.0
>     - 2.1 is equal to 2.1.0
>     - The rest should be obvious
> 

+1, this is great.

> > 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.
> 
> Sounds sane. As long as we're educating people about the fact metadata
> shouldn't be used for arbitrary keys, I'm happy.

Yeah, I'd love to see warnings and even a mode where you can fail on all
warnings so that we can have a strict mode during charm development
but then relax it in production.