From f1ceb53e2abc57df0a567d5603eff0381e86c81f Mon Sep 17 00:00:00 2001 From: Jintao Zhang Date: Fri, 1 Nov 2024 14:56:56 +0800 Subject: [PATCH] chore(kgo-ee): update API reference for v1.4.0 Signed-off-by: Jintao Zhang --- .../reference/custom-resources/1.4.x.md | 68 +++++++++---------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/app/_src/gateway-operator/reference/custom-resources/1.4.x.md b/app/_src/gateway-operator/reference/custom-resources/1.4.x.md index 96e9f04fbdb..e3fd5c23e70 100644 --- a/app/_src/gateway-operator/reference/custom-resources/1.4.x.md +++ b/app/_src/gateway-operator/reference/custom-resources/1.4.x.md @@ -1763,30 +1763,30 @@ Machine Learning models such as Large Language Models (LLM).

The underlying technology for the AIGateway is the Kong Gateway configured with a variety of plugins which provide the the AI featureset.

This is a list of the plugins, which are available in Kong Gateway v3.6.x+:

-- ai-proxy (https://github.com/kong/kong/tree/master/kong/plugins/ai-proxy) -- ai-request-transformer (https://github.com/kong/kong/tree/master/kong/plugins/ai-request-transformer) -- ai-response-transformers (https://github.com/kong/kong/tree/master/kong/plugins/ai-response-transformer) -- ai-prompt-template (https://github.com/kong/kong/tree/master/kong/plugins/ai-prompt-template) -- ai-prompt-guard-plugin (https://github.com/kong/kong/tree/master/kong/plugins/ai-prompt-guard) -- ai-prompt-decorator-plugin (https://github.com/kong/kong/tree/master/kong/plugins/ai-prompt-decorator)

- So effectively the AIGateway resource provides a bespoke Gateway resource - (which it owns and manages) with the gateway, consumers and plugin - configurations automated and configurable via Kubernetes APIs.

- The current iteration only supports the proxy itself, but the API is being - built with room for future growth in several dimensions. For instance:

-- Supporting auxiliary functions (e.g. decorator, guard, templater, token-rate-limit) -- Supporting request/response transformers -- Supporting more than just LLMs (e.g. CCNs, GANs, e.t.c.) -- Supporting more hosting options for LLMs (e.g. self hosted) -- Supporting more AI cloud providers -- Supporting more AI cloud provider features

- The validation rules throughout are set up to ensure at least one - cloud-provider-based LLM is specified, but in the future when we have more - model types and more hosting options for those types so we may want to look - into using CEL validation to ensure that at least one model configuration is - provided. We may also want to use CEL to validate things like identifier - unique-ness, e.t.c.

- See: https://kubernetes.io/docs/reference/using-api/cel/ + - ai-proxy (https://github.com/kong/kong/tree/master/kong/plugins/ai-proxy) + - ai-request-transformer (https://github.com/kong/kong/tree/master/kong/plugins/ai-request-transformer) + - ai-response-transformers (https://github.com/kong/kong/tree/master/kong/plugins/ai-response-transformer) + - ai-prompt-template (https://github.com/kong/kong/tree/master/kong/plugins/ai-prompt-template) + - ai-prompt-guard-plugin (https://github.com/kong/kong/tree/master/kong/plugins/ai-prompt-guard) + - ai-prompt-decorator-plugin (https://github.com/kong/kong/tree/master/kong/plugins/ai-prompt-decorator)

+So effectively the AIGateway resource provides a bespoke Gateway resource +(which it owns and manages) with the gateway, consumers and plugin +configurations automated and configurable via Kubernetes APIs.

+The current iteration only supports the proxy itself, but the API is being +built with room for future growth in several dimensions. For instance:

+ - Supporting auxiliary functions (e.g. decorator, guard, templater, token-rate-limit) + - Supporting request/response transformers + - Supporting more than just LLMs (e.g. CCNs, GANs, e.t.c.) + - Supporting more hosting options for LLMs (e.g. self hosted) + - Supporting more AI cloud providers + - Supporting more AI cloud provider features

+The validation rules throughout are set up to ensure at least one +cloud-provider-based LLM is specified, but in the future when we have more +model types and more hosting options for those types so we may want to look +into using CEL validation to ensure that at least one model configuration is +provided. We may also want to use CEL to validate things like identifier +unique-ness, e.t.c.

+See: https://kubernetes.io/docs/reference/using-api/cel/ @@ -2947,11 +2947,11 @@ _Underlying type:_ `string` PromotionStrategy is the type of promotion strategy consts.

Allowed values:

-- `BreakBeforePromotion` is a promotion strategy which will ensure all new - resources are ready and then break, to enable manual inspection. - The user must indicate manually when they want the promotion to continue. - That can be done by annotating the `DataPlane` object with - `"gateway-operator.konghq.com/promote-when-ready": "true"`. + - `BreakBeforePromotion` is a promotion strategy which will ensure all new + resources are ready and then break, to enable manual inspection. + The user must indicate manually when they want the promotion to continue. + That can be done by annotating the `DataPlane` object with + `"gateway-operator.konghq.com/promote-when-ready": "true"`. @@ -2997,11 +2997,11 @@ _Underlying type:_ `string` RolloutResourcePlanDeployment is the type that holds the resource plan for managing the Deployment objects during and after a rollout.

Allowed values:

-- `ScaleDownOnPromotionScaleUpOnRollout` is a rollout - resource plan for Deployment which makes the operator scale down - the Deployment to 0 when the rollout is not initiated by a spec change - and then to scale it up when the rollout is initiated (the owner resource - like a DataPlane is patched or updated). + - `ScaleDownOnPromotionScaleUpOnRollout` is a rollout + resource plan for Deployment which makes the operator scale down + the Deployment to 0 when the rollout is not initiated by a spec change + and then to scale it up when the rollout is initiated (the owner resource + like a DataPlane is patched or updated).