Rejecting unknown fields in metadata

[Mark Mims]

On 05/14/2012 01: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.
Please be careful that we don't reject a whole local repo just because
one charm has metadata cruft.

I don't see the particular hurry to get this into 12.04, it's not worth
the extra process that probably involves and can wait until 12.04.1 imo.

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


-- 
Mark Mims, Ph.D.
Canonical Ltd.
mark.mims at canonical.com
+1(512)981-6467