Page Comparison

...

...

Have mod-scheduler send egress requests to it’s sidecar like every other module, and add a switch to the module-sidecar which indicates it should retrieve ALL bootstrap info at startup, and consume all discovery eventsprocess all scheduled job events to build and maintain routing information. These information should be stored per tenant basis. It also has to be saved to DB so that after sidecar restarting jobs requests can be handled properly.

Pros

• No special handling required in Kong

• No security concerns

Cons

• 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

1. Risk 1

2. Risk 2 ...

3. Assumption 1

4. 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:

Attachments

Include any relevant attachments, such as documents, diagrams, or presentations that support the spike