I want to change the http interface

Tue Oct 15 10:58:05 UTC 2013

This seems like something we should discuss when we are together next week
and also something we should make sure we get on the schedule for vUDS in
November.

On Tue, Oct 15, 2013 at 5:29 AM, William Reade
<william.reade at canonical.com>wrote:

> 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
>>
>
>
> --
> 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/5bc967ba/attachment-0001.html>