Rejecting unknown fields in metadata

[Juan Negron]

This is great.

I like the juju-version idea ... this will make writing/testing/reviewing
charms a bit more streamlined.
I really like the strict mode idea ... this is something that could be used
in charm proof and promulgate.


Thanks,

Juan



On Tue, May 15, 2012 at 9:36 PM, Clint Byrum <clint at ubuntu.com> wrote:

> Excerpts from Gustavo Niemeyer's message of Tue May 15 12:38:14 -0700 2012:
> > On Tue, May 15, 2012 at 1:54 AM, Clint Byrum <clint at ubuntu.com> wrote:
> > > We absolutely need to enforce a clean composition of charms as much as
> > > makes sense.
> > >
> > > I'm not so sure it makes sense for juju to reject all charms that have
> > > unknown fields in metadata.yaml at every level.
> > >
> > > As a hypothetical, lets say we do this in version 2.0, with the current
> > > set of keys.
> > > Then we add a 'minimum-version' key which allows us to set the minimum
> > > juju version required, in 4.0.
> > > Somebody writes a new charm, tests it on 2.0, and then decides to set
> > > minimum-version: 2.0 because thats best practice.
> > > Except, 2.0 now rejects minimum-version because it is an unknown key.
> >
> > You're right, and I'm happy to relax a bit the constraints on
> > deployment for the reason you point out, as I'm probably being
> > over-strict on the way to educating people that the metadata file is a
> > reserved namespace.
> >
> > Note that the example you provide is not a good one, though. Think
> > about what would happen with version 2.0 when it sees a
> > minimum-version: 4.0 (nothing, and breaks silently).
> >
>
> Agreed, after sending I was thinking that it was probably a confluence of
> two ideas, and not a great way to illustrate the point.
>
> A better example would be a 'tags:' or 'category:' key that would only
> be used by the charm store. We might go back and re-tag everything,
> but that wouldn't mean we went back and broke it.
>
> > Perhaps Kapil is right then, and we should introduce such a
> > "minimum-version" (or "juju-version"?) field now, so that we can make
> > such statements in the future.
> >
>
> Agreed, this exercise has convinced me of that as well. Having a
> minimum-version now means we can start pushing charm features confidently
> as soon as we want to.
>
> This is also good since we can keep track of truly incompatible keys
> as they pertain to the minimum version. So if in v6.0 we add storage
> capabilities that might break previous versions, we can at least have
> 6.0 reject a charm that says minimum-version: 4.0 but then uses the
> storage keys.
>
> > Kapil, in case you decide to go ahead with this, what do you think of
> > the following semantics:
> >
> > - Field format: juju-version: ([0-9]+)(\.[0-9]+)?(\.[0-9]+)?
> > - Semantics:
> >     - 2 is equal to 2.0.0
> >     - 2.1 is equal to 2.1.0
> >     - The rest should be obvious
> >
>
> +1, this is great.
>
> > > I think this calls for warning users about the ignored keys, but not
> > > rejecting. I cannot predict the future, and because of that, I don't
> > > want to sabotage it by having new charms be unnecessarily backward
> > > incompatible.
> >
> > Sounds sane. As long as we're educating people about the fact metadata
> > shouldn't be used for arbitrary keys, I'm happy.
>
> Yeah, I'd love to see warnings and even a mode where you can fail on all
> warnings so that we can have a strict mode during charm development
> but then relax it in production.
>
> --
> 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/20120516/f7b3e4af/attachment.html>