Rejecting unknown fields in metadata

[Kapil Thangavelu]

Excerpts from Gustavo Niemeyer's message of 2012-05-14 12:20:17 -0700:
> 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?

Sounds good (bug: 999338). Out of curiosity what extra fields are people using, 
ie are they typos are just extraneous? 

Fwiw, there has been discussion of 3 new metadata fields for juju over the last 
few weeks.

 - maintainer field
  Currently for official charms there is effectively no record outside of bzr 
  rev logs who is the appropriate person to task with a bug for a given charm, 
  their all assigned to the group. This creates workflow problems as the charm 
  count grows. Afaicr the notion was that this field would includ the lp 
  username of the maintainer.

 - category field 
  Primary purpose is For charm farm/repo user interfaces for which the current
  flat listing is problematic at larger charm counts. This would be a controlled
  vocabulary, and charm authors could indicate their charm matches zero or more
  categories.

 - charm api version field
  As juju evolves and changes available apis to charms, its important that we 
  can capture and possibly accomodate charms written to a different version of 
  that api. At the moment our changes have been primarily additive, but as the
  recent *-get rendering discussion alluded this won't always be the csae.


cheers,

Kapil