feat: Load the SchedulerConfig from a configuration file/text and make it easier to add plugins #881

shmuelk · 2025-05-28T11:50:27Z

This PR adds the ability to:

Define the start of a configuration using yaml text either in-line as an argument or from a file
The configuration for now can be used to:
1. Create SchedulingProfiles
2. Set the ProfilePicker plugin to be used
3. Set any PostResponse plugins to be used
Add additional plugins without the need to modify much existing code.

Fixes #839

This PR adds a configuration of the form:

plugins:
- name: lowQueue
   pluginName: low-queue
   parameters:
     threshold: 10
- name: prefixCache
   pluginName: prefix-cache
   parameters:
      hashBlockSize: 32
- name: maxScore
   pluginName: max-score
- name: profileHandler
   pluginName: single-profile
schedulingProfiles:
- name: default
   plugins:
   - pluginRef: lowQueue
   - pluginRef: prefixCache
     weight: 50
   - pluginRef: maxScore

The plugins section declares the plugin instances to be used in the EPP. A single named plugin instances can be used in multiple SchedulerProfiles as well as in other components of the EPP. It is an array structs with the following fields:

name: A name to be used in the field SchedulingProfile.pluginRef. This field is optional, if omitted the value of the pluginName field will used.
pluginName: names the plugin to instantiate.
parameters: passed unparsed to the named plugin's factory function when creating the instance.

The scheduleringProfiles section defines the set of SchedulingProfiles that will be in the created in the SchedulerConfig. It is an array of structs with the following fields:

name: The name of the SchedulingProfile
plugins: The array of Plugins to be associated with this SchedulerProfile. Each element in this array has the following fields:
- pluginRef: names a plugin instance by the name it was given in the plugins section.
- weight: the weight to be used if the plugin is a Scorer

The startup of the EPP will choose the ProfileHandler plugin and any PostResponse plugins automatically from those specified in the plugins section of the configuration.

To enable the instantiation of plugins from the configuration file/text a singleton/static plugin registry was added. Each plugin was modified to add a factory function. The EPP main() function invokes a new function that registers all of the plugins' factory functions in the registry.

netlify · 2025-05-28T11:50:32Z

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	`ba530cf`
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/68529fda92fd63000850ab7b
😎 Deploy Preview	https://deploy-preview-881--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

k8s-ci-robot · 2025-05-28T11:50:37Z

Hi @shmuelk. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

ahg-g · 2025-05-30T17:37:31Z

/ok-to-test

ahg-g · 2025-05-30T21:48:43Z

pkg/epp/common/config/configloader.go

+	"sigs.k8s.io/yaml"
+)
+
+type Config struct {


I recommend to treat this similar to CRDs so that we version it, and also place this under https://github.com/kubernetes-sigs/gateway-api-inference-extension/tree/main/api/config

See examples:

https://github.com/kubernetes-sigs/lws/tree/main/api/config/v1alpha1

https://github.com/kubernetes-sigs/jobset/tree/main/api/config/v1alpha1

Also, this need to be a generic config api for epp, we need to encapsulate the plugins configuration in its own struct so we can accommodate other parameters (most flags should move here basically)

I'm a bit confused. In the two examples you mention in your comment, while the files are under api/config, they are not really configuration kind of things, but rather true CRDs for CRs that are listened to by the appropriate controllers.

Are you proposing that the config for the EPP be a CRD with the EPP using K8S APIs to listen for it?

Also, this need to be a generic config api for epp, we need to encapsulate the plugins configuration in its own struct so we can accommodate other parameters (most flags should move here basically)

I attempted to make the configuration generic for the EPP, which is why it is under pkg/epp/common/config.

I understand the desire, to place the plugins configuration under a a sub-structure. Which parts exactly did you think should go there (plugin_definitions, profile_picker, and/or scheduler_profiles) ?

I would like to see plugin_definitions and scheduler_profiles as top level items.

scheduler_profiles, while today it is completely about plugins, this may change in the future to include flags and other options.

plugin_definitions, while clearly all about plugins, gets referenced in multiple places in the configuration.

I'm a bit confused. In the two examples you mention in your comment, while the files are under api/config, they are not really configuration kind of things, but rather true CRDs for CRs that are listened to by the appropriate controllers.

They are not CRDs, they don't get deployed on the cluster.

Are you proposing that the config for the EPP be a CRD with the EPP using K8S APIs to listen for it?

No, not deployed as CRDs (i.e., not have a CustomResourceDefinition manifest to deploy them on the cluster). It is still a yaml file we read from a file path. What I am suggesting is that the go struct mimics how we define CRDs, for the most part this means having an inlined metav1.TypeMeta parameter and define a group+version for it.

That is how it was done for the various k8s components like kube-scheduler and kube-controller-manager, and what we are doing for other custom controllers (like Kueue and LeaderWorkerSet).

This helps with versioning and makes us consistent with other projects under k8s.

I attempted to make the configuration generic for the EPP, which is why it is under pkg/epp/common/config.

In other projects under k8s, this was placed under api/config, I suggest to be consistent with that precedence; we can name the struct EndpointPickerConfiguration.

I understand the desire, to place the plugins configuration under a a sub-structure. Which parts exactly did you think should go there (plugin_definitions, profile_picker, and/or scheduler_profiles) ?

When I suggested this, I was thinking about the three sub components that we are trying to make extensible: endpoint picking, flow control and data layer / metrics scraping. I was wondering if we need to split the plugin configuration for each (e.g, a struct for SchedulingConfig, FlowControlConfig and MetricsScrapingConfig)

The other option, which is pretty much what you have in this PR, is to have a single list of plugins across all layers that get registered at the extension points they implement. A slight tweak to the names and types you have:

type EndpointPickerConfig struct { metav1.TypeMeta Plugins []PluginConfig SchedulingProfiles []SchedulingProfile } type PluginConfig struct { Name string Parameters json.RawMessage } type SchedulingProfile struct { Name string Plugins []string // references to plugins }

In the above, we don't even have an explicit ProfilePicker parameter; the profile picker would just be one of the plugins. We can add validations, like only one plugin in the Plugins list implements the ProfilePicker extension point.

I like your second option, with one tweak. The PluginConfig struct needs an additional field, PluginName. The Name field simply provides a name that can be referenced in the SchedulingProfile. This allows for multiple instances of the same plugin with different parameters. An example of this might a Load aware plugin that you want to configure differently for different levels of service.

How would the config be plumped in this case?

If a plugin has one config, it is easy, we only pass it at instantiation time.

The Name field of the PluginConfiguration does NOT refer to the name of the plugin. It is a name that can be referred to in SchedulingProfile entries. There is my proposal (and code) an additional field PluginName that is the name of the plugin (i.e. what the plugin's Name() function returns).

As an aside, there is apparently a proposal to rename the Plugin.Name function to Plugin.Type. That would make things clearer here as well.

@ahg-g I have accepted your suggestion and made the configuration structure K8S CR like and the code now uses the K8S apimachinery runtime to load the structs. There are many other changes as well that I think will make things more acceptable

ahg-g · 2025-05-30T22:07:11Z

pkg/epp/common/config/configloader.go

+}
+
+// Load config either from supplied text or from a file
+func LoadConfig(configText []byte, fileName string, log logr.Logger) (*Config, error) {


Defining it similar to a CRD would allow us to use the decoder pkg from k8s, see this example: https://github.com/kubernetes-sigs/jobset/blob/a7a669590b3483715c193e0af53dbb5f4f066b03/pkg/config/config.go#L19

See my comment above

danehans · 2025-06-03T16:26:27Z

@shmuelk see #881 (comment) for the commit messages that need to be fixed.

danehans · 2025-06-03T16:28:23Z

@shmuelk this PR contains several unrelated commits that need to be cleaned up.

shmuelk · 2025-06-10T16:47:31Z

I have rebased in better fashion, which I hope eliminated this issue

ahg-g · 2025-06-10T22:13:54Z

api/config/v1alpha1/endpointpickerconfig_types.go

+
+	// +required
+	// +kubebuilder:validation:Required
+	Plugins map[string]PluginSpec `json:"plugins"`


See recommendation on using lists: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#lists-of-named-subobjects-preferred-over-maps

The Plugins and SchedulingProfiles fields are now both arrays. A Name field has been added to both.

ahg-g · 2025-06-10T22:22:31Z

api/config/v1alpha1/endpointpickerconfig_types.go

+	PluginName string `json:"pluginName"`
+
+	// +optional
+	Parameters json.RawMessage `json:"parameters"`


in kube-scheduler, we used runtime.Object, probably allows us to use k8s api-machinery functions for decoding https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/apis/config/types.go#L207

Looking at the code in the K8S scheduler, runtime.Object is simply cast to the appropriate type used by the plugin. Those types seem to include a standard K8S TypeMeta stanza. You want every plugin's parameters object to start with apiVersion and kind? You were trying to same extra name tags, isn't here even more acute?

Also if we go with runtime.Object, every plugin with parameters would need to register it's schema in the global schema for the config...

Can we use a secondary schema that this not used/known to the k8s client and only used in configuration?

I do think that the use of Object makes sense as it would natively separate the plugin type from its name, which is currently unclear, IMO. This is a side note - I'll open an issue to discuss to avoid sidetracking the feedback.

ahg-g · 2025-06-10T22:22:52Z

cmd/epp/main.go

-	// --- Initialize Core EPP Components ---
-	scheduler := scheduling.NewScheduler(datastore)
-	if schedulerV2 {
+	// register all of the known plgin factories


Suggested change

// register all of the known plgin factories

// register all of the known plugin factories

ahg-g · 2025-06-11T06:45:23Z

api/config/v1alpha1/defaults.go

+// EndpointPickerConfig struct.
+//
+// This naming convension is required by the defalter-gen code.
+func SetDefaults_EndpointPickerConfig(cfg *EndpointPickerConfig) {


We should use this function to default the parameters of the various in-tree plugins because defaulting is associated with the api version. I believe this function will be automatically invoked the file is decoded.

In general this "extension point" is used to set default values in the CR in question. Look at the examples you pointed me to. I don't think it should be used to specify default values for parameters of plugins. The plugins should handle that themselves.

This could be used, if we wanted to create default configurations, albeit in a round about way.

The in-tree plugins config types should be part of the versioned api, their defaulting should be as well.

See as an example: https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/apis/config/v1/defaults.go

We can handle that as a followup though to keep this PR focused on defining the api.

ahg-g · 2025-06-11T06:48:15Z

cmd/epp/main.go

+	var instantiatedPlugins map[string]plugins.Plugin
+	var scheduler *scheduling.Scheduler
+
+	if len(*configText) != 0 || len(*configFile) != 0 {


recommend to simplify it and validate that only one flag is set, otherwise we will need to define merge semantics.

I want the ability to specify the configuration from a file or from in-line text in the commanmd arguments. Envoy supports this. This enables things like:

containers: - name: epp args: - -poolName - ${POOL_NAME} - -poolNamespace - "default" - -v - "4" - --zap-encoder - "json" - -grpcPort - "9002" - -grpcHealthPort - "9003" - --configText - | apiVersion: inference.networking.x-k8s.io/v1alpha1 kind: EndpointPickerConfig plugins: lowQueue: pluginName: low-queue parameters: threshold: 10 maxScore: pluginName: max-score profileHandler: pluginName: single-profile schedulingProfiles: default: plugins: - pluginRef: lowQueue - pluginRef: maxScore

Perhaps at this point, I'll just add an error message if one specifies both the configFile and configText parameters?

Perhaps at this point, I'll just add an error message if one specifies both the configFile and configText parameters?

sounds good

Done. Added a check in flags validation code

ahg-g · 2025-06-11T06:50:02Z

cmd/epp/main.go

@@ -336,3 +379,21 @@ func verifyMetricMapping(mapping backendmetrics.MetricMapping, logger logr.Logge
 		logger.Info("Not scraping metric: LoraRequestInfo")
 	}
 }
+
+func RegisterAllPlgugins() {


Suggested change

func RegisterAllPlgugins() {

func RegisterAllPlugins() {

ahg-g · 2025-06-11T06:54:05Z

cmd/epp/main.go

+		scheduler = scheduling.NewScheduler(datastore)
+	}
+
+	if reqHeaderBasedSchedulerForTesting {


this is repeated

Moved inside the switch

ahg-g · 2025-06-11T07:12:17Z

cmd/epp/main.go

+	var theConfig *v1alpha1.EndpointPickerConfig
+	var instantiatedPlugins map[string]plugins.Plugin
+	var scheduler *scheduling.Scheduler
+


If no config is provided, we need to use a default one. This actually raises the question of how to disable default plugins. We should probably have a disabled flag in the plugin struct that defaults to false. I will leave a comment on the api file in this regards.

The current code that I have written, will use the existing GIE methods of configuration, is none is provided.

ok, we can do a followup PR to standardize defaulting.

* feat: add health check for epp cluster Signed-off-by: zhengkezhou1 <madzhou1@gmail.com> * remove tls Signed-off-by: zhengkezhou1 <madzhou1@gmail.com> * don't use tls Signed-off-by: zhengkezhou1 <madzhou1@gmail.com> * health checking flag Signed-off-by: zhengkezhou1 <madzhou1@gmail.com> * fix import Signed-off-by: zhengkezhou1 <madzhou1@gmail.com> * add tls options Signed-off-by: zhengkezhou1 <madzhou1@gmail.com> --------- Signed-off-by: zhengkezhou1 <madzhou1@gmail.com>

ahg-g

I think this PR is in a reasonable shape to merge. There are a number of followups to do:

Concrete items to execute on:
- Enable registering out of tree plugins
- Cleanup the scheduler config instantiation paths and converge on one only, for example, when the config flag is not set, start from a default struct.
Open items to still converge on:
- Config API structure, I am still in favor of the approach we currently have.
- Parameters json.RawMessage vs runtime.Object and versioning of the parameters
- Do we want to default the Plugins and SchedulingProfiles parameters? If so, we need to define merging semantics and how to disable a plugin enabled by default (Add a disabled parameter to PluginSpec?)

what do you folks think?

ahg-g · 2025-06-17T15:56:14Z

cmd/epp/main.go

@@ -23,6 +23,9 @@ import (
 )

 func main() {
+	// Register all known plugin factories
+	runner.RegisterAllPlgugins()


We need a way to register out-of-tree plugins, for the example the function could accept a variadic parameter of out-of-tree plugins

nirrozenbaum · 2025-06-17T17:34:23Z

I think this PR is in a reasonable shape to merge. There are a number of followups to do:

Concrete items to execute on:

Enable registering out of tree plugins

Cleanup the scheduler config instantiation paths and converge on one only, for example, when the config flag is not set, start from a default struct.

Open items to still converge on:

Config API structure, I am still in favor of the approach we currently have.

Parameters json.RawMessage vs runtime.Object and versioning of the parameters

Do we want to default the Plugins and SchedulingProfiles parameters? If so, we need to define merging semantics and how to disable a plugin enabled by default (Add a disabled parameter to PluginSpec?)

what do you folks think?

overall I feel comfortable with most of the code in this PR.
few points I still feel could/should be improved are:

the Config API structure - I understand the thinking and the advantages of current approach, but the code is not enforcing that, making it possible for any developer to develop filter+scorer on the same plugin. I believe such decisions should be enforced and not only documented. developers should have the most intuitive path to develop and test a new plugin.
if on the other hand we go on the alternative, it's easier to enforce things on bootstrap (e.g., if one specifies a plugin that doesn't match we can fail fast). documentation should be read in all cases.
another point that I'm not sure was agreed or not - I think we should be able to configure the extension points in both options, via code and via configuration file. Moreover, IMO the configuration file parser should translate the configuration to the same config structs that are used to configure by code. This allows whoever wants from some reason to configure by code to do so, and also has an advantage of easily running unit-tests with code only (without files).
there are few more open points like the ones you mentioned. but we can iterate on those.

shmuelk · 2025-06-18T08:01:05Z

We need a way to register out-of-tree plugins, for the example the function could accept a variadic parameter of out-of-tree plugins

That already exists. Simply invoke the plugins.Register function for any out-of-tree plugins one wants to add.

…#820) Signed-off-by: Ira <IRAR@il.ibm.com>

kubernetes-sigs#980) * Add a metrics to track loaded adapters * Update the sample manifests * Add explanation of metrics from dyanmic LoRA adapter sidecar * Add explanation of metrics from dyanmic LoRA adapter sidecar (take 2) * Update metrics.md based on feedback

…sigs#928) * refactor: Replace prefix cache structure with golang-lru Signed-off-by: Kfir Toledo <kfir.toledo@ibm.com> Co-authored-by: Maroon Ayoub <maroon.ayoub@ibm.com> * fix: rename prefix scorer parameters and convert test to benchmark test Signed-off-by: Kfir Toledo <kfir.toledo@ibm.com> * feat: Add per server LRU capacity Signed-off-by: Kfir Toledo <kfir.toledo@ibm.com> * fix: Fix typos and error handle Signed-off-by: Kfir Toledo <kfir.toledo@ibm.com> * fix: add safety check for LRUCapacityPerServer Signed-off-by: Kfir Toledo <kfir.toledo@ibm.com> --------- Signed-off-by: Kfir Toledo <kfir.toledo@ibm.com> Co-authored-by: Maroon Ayoub <maroon.ayoub@ibm.com>

…ernetes-sigs#834) * copy of accepted inference pool test to start from. * add yaml file for the test * update time out * update the yaml file to add port 9002 * read timeout config from local repo * remove excess comments * correct spelling for scenarios * check route condition on RouteConditionResolvedRefs * remove empty lines in yaml * set optional/defaulted fields as unspecified * fix timeout * fix boilerplate header * change varialbe names to use primary secondary consistently. * remove extra comments * factor out common code * Add actual http traffic validation using echo-basic * remove extra comments from manifest * remove modifiedTimeoutConfig.HTTPRouteMustHaveCondition per review comment. * intermediate update * fix the test run * factor out common code * move epp def to shared manifest * remove extra comments * revert back to two epps * add to do for epp image * switch to GeneralMustHaveConditionTimeout * undo gateway version changes * remove unused HTTPRouteMustHaveConditions * update doc string for GetPod * update docstring * Remove resource type from names in manifests. * remove type from name * remove health check * add todo for combining getpod methods

Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>

ahg-g · 2025-06-18T17:57:26Z

api/config/v1alpha1/endpointpickerconfig_types.go

+	// +required
+	// +kubebuilder:validation:Required
+	// PluginName specifies the plugin to be instantiated.
+	PluginName string `json:"pluginName"`


another follow up is to probably change this to "type" @elevran

ahg-g · 2025-06-18T18:52:52Z

/approve
/lgtm
/hold

@elevran @kfswain @nirrozenbaum

nirrozenbaum · 2025-06-18T18:55:40Z

/lgtm

would be easier to iterate after merging.

kfswain · 2025-06-18T19:02:22Z

/approve

Agreed, this is workable.

/unhold

k8s-ci-robot · 2025-06-18T19:02:32Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahg-g, kfswain, shmuelk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [ahg-g,kfswain]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label May 28, 2025

k8s-ci-robot requested review from danehans and robscott May 28, 2025 11:50

k8s-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label May 28, 2025

k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label May 28, 2025

k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 30, 2025

ahg-g reviewed May 30, 2025

View reviewed changes

k8s-ci-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Jun 4, 2025

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 11, 2025

ahg-g mentioned this pull request Jun 11, 2025

refactor: Move scheduling parameter updates to main #951

Closed

ahg-g reviewed Jun 11, 2025

View reviewed changes

shmuelk changed the title ~~feat: Load the SchedulerConfig from a configuration file/text and make it easier to add plugins~~ [WIP] feat: Load the SchedulerConfig from a configuration file/text and make it easier to add plugins Jun 11, 2025

k8s-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 11, 2025

shmuelk force-pushed the config-loading branch from bd53a98 to b4fe73b Compare June 11, 2025 10:00

k8s-ci-robot removed do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Jun 11, 2025

caozhuozi and others added 3 commits June 17, 2025 09:45

fix dead links (kubernetes-sigs#989)

6386cd6

Merge branch 'main' into config-loading

17d6993

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 17, 2025

ahg-g reviewed Jun 17, 2025

View reviewed changes

k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 17, 2025

irar2 and others added 7 commits June 18, 2025 13:13

Server unit test and utility to help with such tests (kubernetes-sigs…

642b9e5

…#820) Signed-off-by: Ira <IRAR@il.ibm.com>

configuration implementation (after rebase...)

a15557e

Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>

After review, made code more obvious

e1fc8c9

Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>

Merge branch 'main' into config-loading

c5f78f9

k8s-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 18, 2025

Fixed merge issues

ba530cf

Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>

elevran mentioned this pull request Jun 18, 2025

Adding Type() to Plugin interface #1008

Open

ahg-g reviewed Jun 18, 2025

View reviewed changes

k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 18, 2025

k8s-ci-robot assigned ahg-g Jun 18, 2025

k8s-ci-robot added lgtm "Looks good to me", indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jun 18, 2025

k8s-ci-robot assigned nirrozenbaum Jun 18, 2025

k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 18, 2025

k8s-ci-robot merged commit 7bd2053 into kubernetes-sigs:main Jun 18, 2025
9 checks passed

	// register all of the known plgin factories
	// register all of the known plugin factories

feat: Load the SchedulerConfig from a configuration file/text and make it easier to add plugins #881

feat: Load the SchedulerConfig from a configuration file/text and make it easier to add plugins #881

Uh oh!

Conversation

shmuelk commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify bot commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for gateway-api-inference-extension ready!

Uh oh!

k8s-ci-robot commented May 28, 2025

Uh oh!

ahg-g commented May 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ahg-g Jun 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danehans commented Jun 3, 2025

Uh oh!

danehans commented Jun 3, 2025

Uh oh!

shmuelk commented Jun 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shmuelk commented May 28, 2025 •

edited

Loading

netlify bot commented May 28, 2025 •

edited

Loading

ahg-g Jun 3, 2025 •

edited

Loading

shmuelk commented Jun 10, 2025 •

edited

Loading

shmuelk Jun 11, 2025 •

edited

Loading

nirrozenbaum commented Jun 17, 2025 •

edited

Loading

ahg-g Jun 18, 2025 •

edited

Loading