I want to change the http interface

David Cheney david.cheney at canonical.com
Fri Oct 11 02:59:48 UTC 2013


Thanks Sidnei and David for your replies.

David, i'll respond to your points in your mail next but I wanted to
give some feedback on the relation driven proxy approach.

As a user of Juju, and this is what we put in our documentation, we
say, anything that provides the http interface can be connected to
anything that requires the http interface. This magic sniffing and
extending of the http interface with magic keys, which the charm _is
not required to provide to meet the http interface_ breaks this
promise to juju users.

I'm sorry for the use of the word magic, I do not mean to be disrespectful.

My previous statement, "charm is not required to provide to meet the
http interface" is at the crux of my request to change the http
interface so that anything HAproxy has all the information to
correctly proxy anything which is related to.

To give an example

juju deploy wordpress w1
juju deploy wordpress w2
juju deploy haproxy p1
juju add-relation w1 p1
juju add-relation w2 p1
juju expose p1

Will create a configuration where requests landing on p1 for the
vhosts of w1 or w2 will be randomly assigned to either service.

Who's fault is this ? Is it mine for not reading the README ? Maybe,
but if we wanted Juju users to just RTFM, then maybe they could just
RTFM for how to do this all by hand.

Is it the Wordpress charm's fault for not setting those extra keys to
enable it to work correctly with HAProxy ? Maybe, but the author did
faithfully implement the http interface, so I think they are entitled
to push back on that.

My point is this should just work. The promise of relations is if Juju
lets you relate two endpoints, because they have matching
requires/provides interface, then it just works.

If I haven't done enough damage yet.

The haproxy requires relation is broken. As a requires relation it has
a maximum number of things it can relate to of 1 unless the optional
limit key is provideded. This key is not present so HAProxy may only
require one http relation. The gui gets this right, and this caused a
massive amount of confusion. In short, HAProxy, by the strict reading
of the spec only accepts a single upstream http provider.

Cheers

Dave

On Thu, Oct 10, 2013 at 10:07 PM, Sidnei da Silva
<sidnei.da.silva at canonical.com> wrote:
> 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



More information about the Juju mailing list