I want to change the http interface

David Britton david.britton at canonical.com
Tue Oct 15 14:05:27 UTC 2013

Mark, William, Dave --

I agree we should have a session in SFO ...Good timing and all.

On Tue, Oct 15, 2013 at 4:58 AM, Mark Canonical Ramm-Christensen <
mark.ramm-christensen at canonical.com> wrote:

> 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
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju

David Britton <david.britton at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131015/4b86f9de/attachment.html>

More information about the Juju mailing list