Rejecting unknown fields in metadata

[Gustavo Niemeyer]

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).

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.

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

> 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.


gustavo @ http://niemeyer.net