...
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 ...
Conclusion
...
Future Considerations
The use of an all-powerful system user is a potential risk which we’d like to address at some point. The high level idea is to instead provision and use system users with distinct capabilities. In order for this to happen changes would need to be made to module descriptors since many of these timers are defined w/o requiredPermissions. One potential gotcha here is with backward compatibility. We need to ensure that specifying required permissions on these system timer interfaces will not break things when using OKAPI.
Conclusion
Let’s go with 1.2, and in parallel look into how we can possibly adopt option 3 as well. We’d like to consolidate the mechanisms used by the sidecars for obtaining discovery information. We don’t want 2 or 3 ways this is done.
Spike Status:
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
Attachments
Include any relevant attachments, such as documents, diagrams, or presentations that support the spike