I want to change the http interface

Sidnei da Silva sidnei.da.silva at canonical.com
Thu Oct 10 11:07:31 UTC 2013


Hi David,

On Thu, Oct 10, 2013 at 12:31 AM, 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.
>

So, haproxy already supports this in some ways. In fact, I would like to
propose a bigger change that spans all services and relations, but let's
leave that to a separate email...

Actually... seems like my branch [1] never got through so some what I say
below will only be true when it's merged.

The haproxy relation (and similarly apache [2] and squid-reverseproxy [3])
do support a 'service_name' (and alternatively a space-separated
'sitenames' for hysterical raisins) to specify which specific backend a
service should be attached to. So the decision of which service ends up
being attached to which backend is, in the case of haproxy:

1. does the service specify service_name?
1.1 is there a listen stanza for that service name specified in haproxy
'services' config? then append this service to that listen stanza.
2. does the service specify sitenames?
2.1 for each name in sitenames.split(), if there's a listen stanza, append
to that.
3. is there a listen stanza named '<service-name>_service'? (eg:
w1_service, w2_service in your example)?
3.1 if yes, then append to that.
4. is there a listen stanza named exactly '<service-name>' (eg: w1, w2 in
your example)?
4.1 if yes, then append to that
5. all failing, append to the 'default' listen stanza (which I fail to
remember what it means).

That allows for different use-cases:

A. reverse-proxying more than one service, provided you configured more
than one listen stanza via haproxy 'services' config option on separate
ports
B. reverse-proxying to multiple services *within the same listen stanza*,
which is important for the full-service replacement case with canaries
use-case (eg: w1 has N instances, bring up w2 on a separate charm revision
with M instances where M < N, but as part of the same listen stanza, check
for errors on w2 that are not happening with w1, if all is good, ramp up w2
units and ramp down w1 units).

Now, that doesn't mean it solves your problem. From what I understand, what
you want is to have a single 'frontend' stanza with multiple 'backend'
stanzas, and route requests to specific 'backend' stanzas based on either
path or hostname (or both).

I did in fact recently change the haproxy charm to use frontend/backend
stanzas and specifying acls in the frontend stanza, so that should be
possible to do with little effort on top of my branch.

OTOH, I feel like the haproxy charm is already carrying a bunch of
historical cruft (service_name vs sitenames vs <service>_service and so
on), and all those 3 charms would definitely benefit from a review and
consolidation around the http interface to ensure they support the two
use-cases above plus your new one.

[1]
https://code.launchpad.net/~sidnei/charms/precise/haproxy/trunk/+merge/181421
[2]
https://code.launchpad.net/~sidnei/charms/precise/apache2/trunk/+merge/159620
[3]
https://code.launchpad.net/~sidnei/charms/precise/squid-reverseproxy/trunk/+merge/181446

-- 
Sidnei

Make the most of Ubuntu with Ubuntu One
http://one.ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131010/58b51147/attachment.html>


More information about the Juju mailing list