<div dir="ltr">Dave --<div><br></div><div>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.</div>
<div><br></div><div>Reading that back, it may not make sense.  Let me know.</div><div><br></div><div>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.<br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 10:31 PM, David Cheney <span dir="ltr"><<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right, now I have your attention, let me explain my problem.<br>
<br>
I've been assigned to improve the HAProxy charm and the specific issue<br>
I have is the current implementation will place any http requires<br>
relation into the same configuration block [1]. The short summary of<br>
this bug is, if I do this<br>
<br>
   juju deploy wordpress w1<br>
   juju deploy wordpress w2<br>
   juju deploy haproxy p1<br>
   juju add-relation w1 p1<br>
   juju add-relation w2 p1<br>
<br>
then w1 and w2 will be randomly chosen as backends for any request<br>
hitting p1 even though they represent separate services.<br>
<br>
Now, there is no reason that the HAProxy charm has to do this, it's<br>
probably just a combination that<br>
<br>
1. there is no limit setting on the relation, which for a requires<br>
relation implies a limit of 1<br>
2. juju doesn't respect that limit<br>
<br>
So, right now, whether we like it or not, it is completely valid, from<br>
the POV of some using a charm to relate HA proxy two or more services<br>
providing the http interface and to expect it to work (for undefined<br>
values of work)<br>
<br>
Ok, so why doesn't it just work ? HAProxy supports vhosts, and we can<br>
put each http relation into it's own vhost.<br>
<br>
Well, while that is true, the http interface as i *believe* it is<br>
specified today, only includes these two atoms, hostname, and port.<br>
This is not sufficient to reverse proxy more than one service as<br>
individual vhosts inside a single HAProxy charm.<br>
<br>
At a minimum, to solve my problem, I would need the http interface to<br>
define two more atoms, vhost_name (or something equivalent) and<br>
proxy_path.<br>
<br>
vhost_name is self explanatory, but cannot be inferred from the relation name<br>
proxy_path is also important as you may use HAProxy to combine several<br>
different http providers each of who manage a different path prefix of<br>
a single vhost.<br>
<br>
Thoughts ? And while we're at it, why isn't there a schema for<br>
interfaces as there is for the configuration of a provider ?<br>
<br>
Dave<br>
<br>
[1] There are also other problems with this charm, but I will save<br>
them for later novella.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>David Britton <<a href="mailto:david.britton@canonical.com" target="_blank">david.britton@canonical.com</a>></div></div>

</div>