Replies: 2 comments
-
|
+1 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
This is completed. Closing the discussion. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Problem:
Currently, the gateway controller uses custom xDS implementations for specific resources (e.g., API keys) and this works but doesn’t scale as we add more resources that needs to be shared with policy engine at runtime. We need a generic pipeline that can send any resource type from the controller to the policy engine, avoiding per-resource implementations and enabling future use cases.
Proposed Solution:
The proposed structure uses a simple, extensible format:
{ID, Resource_Type, Resource}. This allows the controller to push different resource types through a single xDS channel, and the policy engine can route them to appropriate handlers based on Resource_Type and it will replace ad-hoc approaches (like passing data via route metadata) with a consistent, maintainable mechanism for controller-to-policy-engine communication.Sample Use Cases
LLM Provider Details: For passing LLM provider definitions and their associated template configurations which can be then accessed at runtime by provider ID or API ID, enabling policies to leverage provider-specific information for various operations.
Application and Subscription Management: Applications can subscribe to APIs with subscription policies (throttling tiers, rate limits, etc.). The policy engine needs application metadata, subscription details, and associated throttling policies to enforce subscription-based rate limiting, quota management, and analytics attribution. This data should be pushed from the controller when applications are created, updated, or when subscriptions change.
API Metadata and Context: The policy engine may need additional API-level metadata that isn’t part of the route configuration, such as API owner information, organization details, environment-specific settings, or custom attributes. This metadata can be pushed via the generic pipeline and accessed by policies at runtime.
Custom Resource Types: Future features may require new resource types should have a generic pipeline that provides a foundation for these without requiring new xDS implementations.
Beta Was this translation helpful? Give feedback.
All reactions