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
