I want to change the http interface

[David Britton]

Hi Dave --


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

>
> 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 really don't think point 2 is making the problem worse.  You would still
have an http interface on haproxy that would cover the single tcp/udp
service on each juju service case.  The haproxy charm could be made smarter
to allow it to not choke if distinct juju services are related to it.  It
would just need to properly namespace the listen stanzas with the joining
service name when it writes out.  So that is one work item.

Next, For charms that have a more complex service that involve multiple
ports that need to be proxied from the same juju service.  The simple
concept of "http" no longer works if it's constrained to one hostname and
one port.  It may have 5 ports that each need to be individually specified
to haproxy (and addressable distinctly on the frontend).  In that case, we
go with your point 2: A new interface.

Not to pile on here, but the same goes for the other side of the haproxy
charm -- currently called "website", using the "http" interface.  This is
used for instance, to hook up to an SSL endpoint like apache2.  It has been
extended to supply an "all_services" setting that will fill out service =>
host:port mappings so that apache knows what different named services
haproxy is exposing on the frontend and what ports are associated. (In the
apache case, this information is used to rewrite a vhost template file).
 That would need to be fit into this model as well.

A couple implementation details/notes for when the time comes:

- I'm not in love with the yaml structure that is used in the "services"
key.  That was borrowed from something that the charm already expected.
- I'd rather have the charm expect a simplified structure with just service
name mapped to port, with more complex settings (like timeouts, httpcheck,
etc) specified optionally in another setting and defaulted to something if
left empty.
- Maybe the interface name of reverseproxy:haproxy-services? I'm not sold
on that, just throwing something out there.


Thanks for broaching this subject.  Hopefully we can work something out.

-- 
David Britton <david.britton at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131010/7c0450fa/attachment.html>