I want to change the http interface

[David Cheney]

Hi David,

I think i've probably covered a lot of this in my last reply.

> 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.

My problem with this setup is it is not enforced by the interface. The
http interface specifies two atoms, hostname and port, all the extra
stuff that is relation-set is optional, and there is no way for
HAProxy to know that is has been related to a service which provides
these optional, but critical configuration items.

>  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.

Yup, the use case I have right now is customers who are asking why
they need to run a HAProxy per service. Yes, as you have shown,
HAProxy can do this, but not if the charm, which they got out of our
charm store, does not implement this.

> 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.

I have two possible solutions, neither good.

1. define the http interface with more atoms so that the
relation-driven approach is baked into the specification of the
interface. This is a big job as I don't think anyone has tried to
upgrade an interface before.

2. define a new interface, say, reverseproxy which is the superset of
http, and includes all the other relation-driven optional keys, but
that may make the problem worse, providing a http interface won't let
you be proxied by HAProxy, you'd need to also provide a separate
reverseproxy provides relation.

I don't know what the best solution is, but I do know that I want to
be able to support that if two service relations have the same
interface, they should work together.

Cheers

Dave