Er, it's not `proxy_url`, it's `scheduler_uri` (which makes much more sense ;)).
On Mon, Apr 18, 2016 at 5:34 PM, Joshua Cohen <jco...@apache.org> wrote: > 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 >> > >
