I want to change the http interface

[David Britton]

Dave --

I think what you want is described as "Relation-driven proxying" in the
README.md.  In this style of reverse proxy, you can specify a full listen
stanza (in a weird YAML way), for all services that you need haproxy to
front-end.  haproxy will then take all stanzas supplied and union them into
a data structure that it then exports to its config file.  The nice thing
about using that style of proxying is that it allows multiple juju services
to describe what they want without trampeling on each other.  IOW, It
allows just one haproxy to serve multiple distinct juju services and what
are potentially multiple tcp/udp services that a charm is actually
responsible for on a single unit.

Reading that back, it may not make sense.  Let me know.

I wrote this part of the charm initially, and having said that, I agree
with Sidnei that there is lots of historical cruft (hysterical raisins) in
there that could be re-thought.  But, there are many charms that are made
to work with haproxy now, probably.  If we change it, we should get it
right.



On Wed, Oct 9, 2013 at 10:31 PM, David Cheney <david.cheney at canonical.com>wrote:

> 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 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/20131010/5b847237/attachment.html>