Amit Kumar Gupta
Several components within cf-release, as well as many jobs in different
releases, register a route with the gorouter:
- *doppler* registers the "doppler" and "loggregator" routes
- the *hm9000* API server registers the "hm9000" route
- *UAA* registers "uaa", "*.uaa", "login", and "*.login" routes
- *CC* registers the "api" route
- Many *service brokers* also register a route.
All these components register their routes in different ways. They also
all use the existing NATS flow, and will all need to switch their
implementations to use the routing API once that goes live and we start to
phase out NATS.
We have been working on extracting a route-registrar job which can be
colocated with other jobs and register routes on their behalf. Currently
it naively just always advertises the configured routes, and relies on the
gorouter's behaviour around knowing not to route requests to addresses that
aren't currently up.
One might require more sophisticated logic than this, however. For
example, a server may be "up" and theoretically capable of handling
requests, but not actually ready yet. Perhaps the router-registrar should
have some contract with its colocated jobs where those jobs can define a
health check script, and the route-registrar will only update the route
registration if the check succeeds.
Another requirement may exist around shutdown behaviour. Jobs may only
want to stop having its routes registered at a certain point in its drain
*We would like feedback* from anyone maintaining a job or release that does
some sort of route registration to gather requirements that would be
desired of a generic route-registration component.
Amit, CF OSS Release Integration team