I want to change the http interface
david.cheney at canonical.com
Wed Oct 16 02:48:24 UTC 2013
> 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,
I have to disagree with you there. The promise of the relation, the
promise that we tell users in charm schools and training is that if
you charm provides an interface, say "http", then it can be connected
to anything that requires a http interface. As I have shown, that
promise has been broken.
it's hard to be *sure* what a given
> interface means without reading and/or running code . 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
>  to avoid things going wrong). But it's also clear that we need to fulfil
> this use case.
Here is my beef, the HAProxy charm says it requires the 'http'
relation, but actually it requires something completely different.
That thing doesn't have a name, but it certainly doesn't confirm to
the informal expectation of what Wordpress provides, or what Juju-GUI
provides, or what phpadmin provides, to name three examples at random,
when they provide the http relation.
> * 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
What does extending an interface mean if implementing an interface
means you can execute zero calls to relation-set ?
> name: haproxy
> reverseproxy: http
> interface: http
> limit: 0
> gets: [vhost, proxy-path]
> name: old-n-busted
> website: http
> name: new-hotness
> 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
This is my complaint with the second option I proposed, it breaks the
promise that we make to our users. If wordpress, or the gui provides
the 'http' relation, it is no longer sufficient for charms that want
to act as proxies, because they required more than the traditional two
fields those charms relation-set. So the promise then becomes, if you
want your charm to be proxyable, you have to implement a second
relation. And similarly products like HAProxy can only proxy charms
that advertise themselves as such via this second provides relation.
> 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?
Why can't we have a schema for interfaces ? One where, like charm
configuration values, there are defaults and required fields. This
would solve all my issues.
>  https://juju.ubuntu.com/docs/authors-charm-interfaces.html
>  https://bugs.launchpad.net/juju-core/+bug/1089297
>>  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:
More information about the Juju