series-agnostic charm URLs

[William Reade]

On Thu, Jul 24, 2014 at 12:59 AM, roger peppe <roger.peppe at canonical.com>
wrote:

> On 23 July 2014 11:51, John Meinel <john at arbash-meinel.com> wrote:
> > Casey is the one to talk to. I'm not sure if he was just trying to be
> > conservative, but he did intentionally not want to pun the types. I
> think he
> > wanted to be clear that things passed to *these* API calls must be fully
> > formed, while ones passed to *those* could be expanded.
> > We could do what you say, but it starts meaning every API that takes a
> URL
> > has to start worrying about expanding it late.
> > Since it is no longer "charm.URL" but really "charm.MaybeURL".
>
> Luckily there are no APIs that currently take a URL type as an
> argument. The only ones that do (ServiceDeploy, for example)
> currently use a string, because they allow a partially specified
> URL, so can't use charm.URL.
>

WTF? We have charm.InferURL *and* charm.ParseReference for the cases where
sloppy input is reasonable -- charm.ParseURL should *parse a URL*, and fail
if not given a string that represents a URL.

And ServiceDeploy should *definitely* not accept sloppy input: I'm certain
we had exactly this argument back in the early API days, and looking at the
code STM to imply that a reasonable attempt was made to follow my
instructions -- ie ServiceDeploy will fail if the charm revision is not
specified, as it *should* if the schema or series or anything else is left
unspecified.

Anyway, someone changed some code and introduced a bug that got missed in
review; it happens. However, someone now needs to go into the charm package
and add some tests to ParseURL to ensure it errors as it should when
schema, or series, is omitted.

Note that not even charm.URL is itself currently necessarily fully
> specified - the revision can be omitted.
>

It's a valid charm URL with or without a revision. It is *not* a valid
charm URL without a schema, series, or name. These definitions have not
changed in years.

On 23 July 2014 13:01, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> > On Wed, Jul 23, 2014 at 7:35 AM, roger peppe <rogpeppe at gmail.com> wrote:
> >> We want to store charm URLs in mongo-db that are agnostic whether
> >> the series is specified or not. For example, in a bundle, a service
> >> is free to specify a series in the charm name or not.
> >
> > That sounds slightly surprising. How do we plan to define what the
> > bundle actually means?
>
> The charm URL in a bundle means exactly what it would mean if
> you typed it in a juju deploy command. That is, it is dependent
> on the charms available at bundle deploy time.
> An unspecified revision uses the latest available revision;
> an unspecified series uses the latest LTS series that's
> available for the charm.
>

This makes me shudder -- why would we want to encourage distribution of a
format encoding vague guesses as to validated best practice, rather than
encoding *actual* validated best practice? `juju deploy foo` is great for
demos and exploration, but I'd expect any serious user to value
reproducibility enough to specify the actual charm precisely; and for them
to expect that the bundles they use would do the same.

> As noted above, a Reference may not have a schema as well, so this
> > suggestion seems to imply that "foo" becomes a valid URL.
>
> Yes, both ParseURL and ParseReference both already allow
> the schema to be omitted, defaulting to "cs:" if so.
>
> > Maybe having just URL could be made cleaner, though. This should
> > be judged based on a more detailed proposal.
>
> I do believe having just URL would be significantly cleaner.
> What area would you like to see more detail on?
>

Fuzziness over the meaning of URL appears to have already broken ParseURL,
and hence ServiceDeploy; let's not double down on that. Even if the bundle
format's sloppiness is already entrenched, that's no reason for juju-core
to give up and just start accepting whatever -- the clients can damn well
rewrite sloppy bundles before using them with juju, just as they should,
and do (or at least *did*... who knows what's happened recently since
validation got broken) rewrite sloppy charm URLs before passing them to
juju.

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140725/b7602933/attachment.html>