Re: feedback request: extracting a common route-registrar job
Amit Kumar Gupta
Hey all,
toggle quoted message
Show quoted text
The router already has some health check behaviour -- you can naively register routes with it and it's smart about knowing whether to actually route traffic or not. I'd like to understand what the specific use cases are that would require a route-registration job to support additional custom health check logic provided by the various colocated jobs. Here's the set of things that are being done/need to be done for this track of work: 1. extract route-registration process from UAA job in cf-release into its own job in cf-release (note that the new uaa-release doesn't have this process) [story done, needs acceptance] 2. use this route-registration job colocated with UAA in the cf manifests. [story done, needs acceptance] 3. use this route-registration job colocated with CC, HM9k, and doppler in the cf manifests. [stories in flight] 4. discover additional requirements for a generic route-registration job to be useful [this email thread] 5. implement features in route-registration job to satisfy requirements 6. wait for consul to be declared stable, and enable the routing-api as a default part of cf deployments [next couple final versions of cf-release will validate consul] 7. all things doing route-registration should use routing-api 8. extract route-registration job out of cf-release (and put it where?) in order to make it usable by other things like Gemfire, MySQL, Riak, etc. 9. discover more additional requirements for a generic route-registration job to be useful 10. implement more features in route-registration job to satisfy requirements 11. implement more features in routing-api to satisfy requirements This isn't necessarily an ordered list, however we want to extract and start using the route-registration stuff early to discover requirements, and whether it's even a feasible idea, rather than waiting on consul and routing-api to validate it. A nice additional consequence of doing this extraction early is that once we want to switch over to routing-api, it only needs to be done in one place. Jens, Here is a story in the Routing backlog to enable the routing-api to support sticky-session route registrations: https://www.pivotaltracker.com/story/show/100327146 Best, Amit
On Tue, Sep 8, 2015 at 3:43 PM, Lyle Franklin <lfranklin(a)pivotal.io> wrote:
The mysql and riak services register routes with this guy: |
|