Re: I want to change the http interface
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-christen...@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.re...@canonical.com wrote: On Thu, Oct 10, 2013 at 6:31 AM, David Cheney david.che...@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
Re: I want to change the http interface
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 [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. 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 following: What does extending an interface mean if implementing an interface means you can execute zero calls to relation-set ? 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?). 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
