Rejecting unknown fields in metadata

[Gustavo Niemeyer]

We've discussed this over sessions at UDS, so I'd just like to present
the idea to the community at large before we do any changes, and also
to understand how we'll put the change in place.

The change being proposed is to reject any fields within metadata.yaml
files that are not part of the documentation and implementation of
juju at the moment. People are already start to use metadata.yaml in
an uncontrolled manner, which is damaging to the community itself,
first because people will be assigning different meanings to the same
field, and most critically because juju will grow new fields in the
future that may conflict with these ad-hoc fields and cause the system
to misbehave in a way we can't understand or avoid. All of that in
exchange for absolutely no benefit, given that anything that is put
within metadata.yaml in such manner could be put equally well in a
file named mymeta.yaml or anything else.

For those reasons, I suggest we take the following steps to prevent such usage:

Phase 1: Modify the juju in 12.04 so that it refuses to deploy any
*local* charms with unknown metadata.yaml fields, and *warns* about
such fields in remote charms (so that it continues to work with
existing bogus charms in the store). This should be put onto the
updates for 12.04, and also in 12.04.1.

Phase 2: Refuse new charms in the store with unknown fields, and
refuse to deploy remote charms with unknown fields as well. This is
may land in 12.10 only.

Can we push that?


gustavo @ http://niemeyer.net