aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Isaac Councill (JIRA)" <>
Subject [jira] [Commented] (AURORA-761) Provide a proxy for generic service discovery
Date Wed, 15 Oct 2014 21:07:33 GMT


Isaac Councill commented on AURORA-761:

The statement that a consul call is better for us than a ZK lookup came from use cases in
ops. Let's take that off the table, as we've worked through those cases locally.

The DNS caching issue really is a killer for the consul approach. Without being able to rely
on DNS there's really no other compelling reason to add such complexity to the stack (which
was looking objectionable by itself). I'm willing to consider the consul approach explored
and rejected. Actually, happy with that outcome.

Since there's interest here and great comments (thank you), I'd like to put together a doc
for your comments/criticism that would involve just the use of HAProxy with a binding layer.
We're looking at bamboo and synapse for inspiration and prior art. Any other pointers welcome.
I'll post here when a first draft is ready.

> Provide a proxy for generic service discovery
> ---------------------------------------------
>                 Key: AURORA-761
>                 URL:
>             Project: Aurora
>          Issue Type: Story
>          Components: Service Discovery, Usability
>            Reporter: Bill Farner
>            Priority: Minor
> While {{Announcer}} provides service registration, we lack a cross-cutting answer for
service discovery.  There are well-known libraries that will do it (e.g. finagle), but we
need an answer for others.  Marathon, for example, provides a script called {{haproxy_marathon_bridge}}
that reloads configuration of HAProxy for this purpose.  We could do something similar with
a mixin {{Process}} that dynamically routes an inbound port to a serverset path in ZooKeeper.

This message was sent by Atlassian JIRA

View raw message