Rejecting unknown fields in metadata

[Juan Negron]

+1 from me as well but, I would like to keep Clint's proposal for a
maintainer field in metadata.yaml.  As long as we keep the maintainer
field, I am ok with rejecting other changes.


Thanks,

Juan


On Mon, May 14, 2012 at 1:20 PM, David Cheney <david.cheney at canonical.com>wrote:

> Both of these proposals sound good to me.
>
> On 15/05/2012, at 5:45, Marco Ceppi <marco at ondina.co> wrote:
>
> > 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
> >>
> >
> >
> > --
> > Juju mailing list
> > Juju at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20120514/b539dd76/attachment.html>