Skip to end of banner
Go to start of banner

EUREKA-211: Spike - Revisit routing of mod-scheduler requests

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 5 Next »

[DRAFT]

Spike Overview

User Story: https://folio-org.atlassian.net/browse/EUREKA-211 Spike - Revisit routing of mod-scheduler requests

Objective: Revisit the decisions made in the wake of EUREKA-89 - Getting issue details... STATUS

See spike findings here: https://folio-org.atlassian.net/wiki/x/BACNCg

The reason to revisit this is that Kong may not know how to route requests to these system interfaces in cases where multiple modules have timers that call the same system interface. It’s also not great that Kong is even aware of system interfaces, given that it only routes traffic from outside the system.

We may want to consider alternative solutions that avoid these problems. For example, we could make the mod-scheduler sidecar aware of all discovery and other relevant info or be able to retrieve it on an as-needed basis.

Problem Statement

Kong's inability to route requests correctly to system interfaces and its awareness of these interfaces are problematic. This routing confusion arises when multiple modules' timers call the same system interface, which is beyond Kong's intended functionality of managing external traffic.

Scope

This spike will explore alternative solutions to the current design to improve request routing for system interfaces. Potential approaches include enhancing the mod-scheduler sidecar to be aware of or retrieve necessary discovery and other relevant information dynamically. The goal is to devise a solution that bypasses the limitations faced by Kong in its current role.

Deliverables

The main idea is to work in detail on option 3 described in the EUREKA-89 Spike - Design solution for scheduled system calls.

There are two possible solutions here, but both of them originate from the same ideas: mgr-applications and mgr-tenant-entitlements contain all the information to identify a correct route that should be used for a particular “timer call” from the mod-scheduler. So, these “timer“ routes should not be configured in Kong, and all the discovery information could be retrieved dynamically when it is needed.

Option 3.1

In general, this option repeats the idea of security and principles described in option 1.2 of the spike https://folio-org.atlassian.net/wiki/x/BACNCg

The following diagram displays the main components and actors involved in the flow.

Flow:

  1. mod-scheduler prepares a request and puts impersonated token for the system user into x-okapi-token request header. Then the request goes from mod-scheduler to its sidecar.

  2. Because Sidecar (mod-scheduler) has dynamic routing enabled and the requested route is not known, it calls the mgr-URLs to resolve the discovery information.

  3. mgr-URLs calls mgr-Tenant-Entitlements to resolve the actual module's version.

  4. mgr-URLs calls mgr-Applications to retrieve the actual discovery information that points to the Sidecar (Module A).

  5. Sidecar (mod-scheduler) dynamically routes the request to the Sidecar (Module A).

  6. Sidecar (Module A) authorizes the request to Module A.

    1. get token from request header

    2. parse token

    3. call Keycloak to evaluate permissions. Since the system user has access to all resources, authorization will be successful

  7. Sidecar (Module A) forwards the request to Module A for processing.

This option introduces a new component, mgr-URLs, that plays a critical role in the routing mechanism for scheduled timer calls within the Folio system. Its primary function is to maintain and manage a cache of routes, which includes resolving the actual routes and versions of modules based on the tenant context.

Key Functions:

  1. Routes Cache with Expiration Policy:

    • Purpose: The mgr-URLs module maintains a cache of routes that includes information about various system/timer interfaces and their respective routes. This cache has an expiration policy to ensure that the information remains up-to-date and valid.

    • Functionality: When a request for a specific route (e.g., /timer-urlA) is received, the module checks its cache for the corresponding route. If the route information is available and valid, it proceeds to use it. If the information is expired or not found, the module queries relevant systems to fetch and update the route information.

  2. Route Resolution:

    • Resolving Routes: The module resolves the actual route for the requested URL, ensuring that the correct path is used for system/timer calls. This involves determining the correct endpoint based on the module version and the specific tenant making the request (e.g., tenant Diku).

    • Integration with Other Modules: It interacts with mgr-Tenant-Entitlements and mgr-Applications to resolve the module version and obtain the correct route information. This ensures that the requests are directed to the appropriate module version and interface.

  3. Lightweight and Simple: mgr-URLs module does not use any persistent storage and integrates only with mgr-Tenant-Entitlements and mgr-Applications

  • No labels