I'm not opposed to this, in fact we already do something similar internally. We've forked clusters.py to allow configuring a `proxy_url` for each cluster. If that's present, then the client will use it rather than performing service discovery to communicate with the scheduler.
On Mon, Apr 18, 2016 at 2:03 PM, John Sirois <jsir...@apache.org> wrote: > As part of work on switching the Aurora scheduler from using a copy of the > Twitter zookeeper libs to the Apache Curator libs [1], I'd like to enable a > Curator feature (GUID protection [2]) that will make the scheduler more > robust to ZooKeeper outages but has the side-effect of breaking the > effectively public API formed by the ZooKeeper path names it uses to > perform leader election and service advertisement. From Aurora's > standpoint, the API consumer is the Aurora command-line client. It uses > service-discovery today to find the leading scheduler to communicate with. > I propose switching the client to use HTTP re-directs instead since the > scheduler already has a redirect service and since this would reduce the > scheduler API surface area and generally move further down the road of a > pure HTTP api. > > The most obvious problem I see here is just the mechanics of a proper > deprecation cycle for all those clients Aurora is not directly aware of > that rely on its service advertisment API in ZooKeeper today. > > Are there other problems folks see with this? > > [1] https://issues.apache.org/jira/browse/AURORA-1468 > [2] https://issues.apache.org/jira/browse/AURORA-1670 >
