Skip to end of banner
Go to start of banner

EUREKA-89 Spike - Design solution for scheduled system calls

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Spike Overview

User Story: EUREKA-89 Spike - Design solution for scheduled system calls

Objective: Select an approach to the problem of routing mod-scheduler calls to system interfaces aka timers

Background

Timers defined in module descriptors sometimes specify endpoints which are not defined as part of regular/standard interfaces. That means information about these is not included in the bootstrap/discovery information sidecars use to route module-to-module calls. Presently, mod-scheduler sidecar sends timer requests directly to Kong in order to simplify things. Also mgr-tenant-entitlement registers timer interfaces as routes in Kong. Without that sidecars would need to either get all discovery information, or obtain new discovery info whenever a new timer is created.

Problem Statement

We discovered that some _timer interfaces point to system interfaces, which, for good reason should not be routed through Kong or at least made publicly available in Kong. This means that calls from mod-scheduler to these endpoints will fail. We must find a solution which works for requests to both public and system interfaces.

Scope

In Scope

  • Egress request routing from mod-scheduler

  • Requests to both public and system interfaces

  • Changes/enhancements to Eureka core components (i.e module sidecars, and/or mod-scheduler, and/or Kong)

Out of Scope

  • …

Research Questions

  1. How should mod-scheduler calls be routed to system interfaces?

  2. What is the relative effort and complexity for each of the solutions?

Deliverables

There are several options but all of them originates from two ideas:

  1. Route system interfaces in Kong, but in such a way that only mod-scheduler is the only valid source of these requests.

  2. Have mod-scheduler send egress requests to its sidecar like every other module, and extend sidecar with ability to retrieve necessary routing information to handle these requests.

Option 1.1

Route all timer request (for regular and system interfaces) through Kong, but in the case of system interfaces, allow requests coming from the internal sub-net only and block any calls to system interfaces from the outside. This type of barrier can be enforced with custom Kong plugin, let’s call it Private Resource Access (PRA) plugin.

The plugin should be aware of network boundaries where Eureka cluster with Folio modules is deployed. How exactly this information can provided to the plugin is TBD. With that knowledge requests to system interfaces can be filtered by requestor’s IP address:

  • request comes from internal node (including a node with mod-scheduler) → let it pass through;

  • request comes from external network (internet) → forbid and return “404 Route not found“, as it’s done in case of unknown route.

The following diagram displays

Folio modules and their sidecars are deployed inside a cluster with predefined private network (marked as Intranet on the diagram). Among other modules the deployment contains mod-scheduler, to run scheduled jobs, and some business module, named “Module A”. Module A provides regular interface /regular-url-A along with _timer interface /timer-url-A. Detailed information about Module A interfaces contained as usual in its Module Descriptor.

  1. At first Tenant Entitlement manager (MTE) enables an application with Module A for a tenant. During this process MTE gets Module Descriptor of Module A and

a. creates routes in Kong for all module’s public interfaces from "provides" section of Module Descriptor

b. creates routes in Kong for _timer interfaces. Each newly created route marked with a special tag “private“ (or “internal“, or “system“) to identify interface as internally available only

image-20240502-122538.png

c. creates (via Kafka) scheduled jobs for Module A _timer endpoints in mod-scheduler

  1. scheduled job is triggered for /timer-url-A endpoint. Request goes from mod-scheduler to its sidecar, which in turns forwards the request to Kong, since the request URL is not registered inside sidecar’s egress routing table

    1. Kong receives the request and searches for known routes associated with the given URL and method. Once the route is found, PRA plugin checks if it has “private“ tag assigned, in case of scheduler

Pros

  • Mod-scheduler and the mod-sidecar remain unchanged

Cons

  • Possible security / entitlement issues

Option 2

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 events.

Pros

  • No special handling required in Kong

  • No security concerns

Cons

  • the sidecar needs to retrieve and manage discovery and interface/endpoint information for all APIs in the system.

Risks & Assumptions

  1. Risk 1

  2. Risk 2 ...

  3. Assumption 1

  4. Assumption 2 ...

Conclusion

Summarize the results of the spike, key findings, and any recommendations or next steps

Spike Status: COMPLETED IN PROGRESS ON HOLD

Attachments

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

  • No labels