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 novella. >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > -- David Britton <david.brit...@canonical.com>
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
