Rejecting unknown fields in metadata

[Marco Ceppi]

On 05/14/2012 03:20 PM, Gustavo Niemeyer wrote:
> 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.

charm proof should also check for extra fields in the charm 
metadata.yaml file and throw and E: when found. Can we also start 
failing charms in the Jenkins setup if they have extra metadata 
information? I'm not sure if the QA system pulls locally then deploys or 
if it does a straight deploy from remote. If it's the latter case we 
won't get eyes on bad charms in the charm store for quite a few months.

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