I want to change the http interface

[William Reade]

On Thu, Oct 10, 2013 at 6:31 AM, David Cheney <david.cheney at canonical.com>wrote:

> Thoughts ? And while we're at it, why isn't there a schema for
> interfaces as there is for the configuration of a provider ?
>

There's no schema for interfaces because, in theory, we can trust
distributed community consensus to keep everybody in honest agreement.
That's worked surprisingly well so far, but I think it will become a
liability at some point -- even today, it's hard to be *sure* what a given
interface means without reading and/or running code [0]. We've already
discussed and agreed in principle that the lack of a global registry of
interface definitions is becoming more important by the day.

It's clear that there are so many relations using the "http" interface out
there that it's essentially impossible to *require* that new fields be
added -- haproxy's reverseproxy relation will basically have to continue to
work against host/port alone (but juju should absolutely start respecting
limits [1] to avoid things going wrong). But it's also clear that we need
to fulfil this use case.

* I'm not keen on using requirer-service configuration to paper over the
lack of expressivity in relations -- we've been stuck with it so far, but I
don't think we want to entrench it.
* I'm definitely not keen on creating a new interface to handle this
situation -- if there's a compelling case for a "super-http" interface,
then there's little reason for a charm author to implement "http" as
well... except that their charm won't work with others that require plain
old "http". But I'd rather not encourage a profusion of almost-identical
interfaces -- it's good for charms to be "sticky", but it's unrealistic to
expect that they all be, uh, multiply-sticky(?) -- I want authors to be
able to provide *one* interface for a single purpose, lest the ecosystem
become irreparably balkanised.
* I think there is a case for allowing interfaces to be *extended* -- in
which "http" still implies the minimal hostname/port, but charm authors
have a path for setting and using vhost/proxy-path with confidence that it
will actually work. I'm thinking of charms with metadata something like the
following:

name: haproxy
requires:
  reverseproxy: http
  multi-reverseproxy:
    interface: http
    limit: 0
    gets: [vhost, proxy-path]


name: old-n-busted
provides:
  website: http


name: new-hotness
provides:
  website:
    interface: http
    sets: [vhost, proxy-path]

...in which:

* "http" always implies get/set of hostname/port, as it does today
* the old-n-busted charm still works with the original reverseproxy
relation, and any charm that just requires "http"
* the new-hotness charm works with the multi-reverseproxy relation
* the new-hotness charm *also* still works with any charm that just
requires "http", because there'd be no obligation to get fields that the
other side sets -- just to set fields that the other side gets.

The most obvious problem is that `juju add-relation haproxy new-hotness`
now fails because the relation spec is ambiguous -- you'd need `juju
add-relation haproxy:multi-reverseproxy new-hotness` -- but I think that's
relatively painless for the "average" user, in that the GUI is in a
position to pick sensible defaults in the case of ambiguity (when multiple
relations over the same interface are possible, default to the more
sophisticated one?).

There may well be other problems -- for example, the ability to *set* good
values for vhost/proxy-path will themselves demand configuration settings
in the new-hotness charm, and while this is a clear improvement over
needing to set them in the requirer's service configuration it's still not
perfect, because there's no way to prevent a user from creating a relation
that requires them. This feels like a specific case of a more general
problem -- that the simplicity of the metadata format prevents us from
expressing cross-cutting restrictions (eg it makes no sense to relate
certain apps to multiple db services, even though the metadata might imply
that both "postgres" and "mysql" are "required") -- that we can only really
currently address in individual charms.

But I bet there are more rough edges that should be knocked off, and maybe
problems I just can't see. Thoughts?

William



[0] https://juju.ubuntu.com/docs/authors-charm-interfaces.html
[1] https://bugs.launchpad.net/juju-core/+bug/1089297



>
> Dave
>
> [1] There are also other problems with this charm, but I will save
> them for later novella.
>
> --
> 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/20131015/4017aaf7/attachment.html>