...
the most complicated solution
the sidecar needs to retrieve and manage discovery and interface/endpoint information for all scheduled job APIs (system / public interfaces) in the system.
scheduler specific logic introduced in sidecar code which is of general purpose
potential grow of memory consumption due to increased volume of routing information
sidecar would need to manage a permanent storage
partial intersection of responsibilities with Kong, it already manages routes for each tenant. Sidecar would need to do the same but for a smaller group of routes
Option 3
Sidecars dynamically retrieve discovery information on an as-needed basis. If this fails, fallback to routing the request to Kong. Maybe this requires a new endpoint in mgr-tenant-entitlements, or maybe not.
Pros
No special handling required in Kong
No security concerns
No need for the sidecars to get ALL discovery information, only what’s required, when it’s required.
Cons
Multiple ways for sidecars to get discovery information
Ask during startup, then get updates via kafka
Retrieve on an as-needed basis
Possibly larger memory footprint required for the mod-scheduler sidecar
Could be mitigated by adding a trait to endpoints indicating whether or not they’re eligible for being scheduled
Risks & Assumptions
Risk 1
Risk 2 ...
Assumption 1
Assumption 2 ...
...