Right, now I have your attention, let me explain my problem. I've been assigned to improve the HAProxy charm and the specific issue I have is the current implementation will place any http requires relation into the same configuration block [1]. The short summary of this bug is, if I do this
juju deploy wordpress w1 juju deploy wordpress w2 juju deploy haproxy p1 juju add-relation w1 p1 juju add-relation w2 p1 then w1 and w2 will be randomly chosen as backends for any request hitting p1 even though they represent separate services. Now, there is no reason that the HAProxy charm has to do this, it's probably just a combination that 1. there is no limit setting on the relation, which for a requires relation implies a limit of 1 2. juju doesn't respect that limit So, right now, whether we like it or not, it is completely valid, from the POV of some using a charm to relate HA proxy two or more services providing the http interface and to expect it to work (for undefined values of work) Ok, so why doesn't it just work ? HAProxy supports vhosts, and we can put each http relation into it's own vhost. Well, while that is true, the http interface as i *believe* it is specified today, only includes these two atoms, hostname, and port. This is not sufficient to reverse proxy more than one service as individual vhosts inside a single HAProxy charm. At a minimum, to solve my problem, I would need the http interface to define two more atoms, vhost_name (or something equivalent) and proxy_path. vhost_name is self explanatory, but cannot be inferred from the relation name proxy_path is also important as you may use HAProxy to combine several different http providers each of who manage a different path prefix of a single vhost. Thoughts ? And while we're at it, why isn't there a schema for interfaces as there is for the configuration of a provider ? 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
