-
Notifications
You must be signed in to change notification settings - Fork 206
Extend textual configuration support with the Datalayer's configuration #1914
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: shmuelk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
df1171b to
a2a0cec
Compare
| func (cfg EndpointPickerConfig) String() string { | ||
| return fmt.Sprintf( | ||
| "{Plugins: %v, SchedulingProfiles: %v, FeatureGates: %v, SaturationDetector: %v}", | ||
| "{Plugins: %v, SchedulingProfiles: %v, Data: %v, FeatureGates: %v, SaturationDetector: %v}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: put feature gates first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
| The saturationDetector section configures the saturation detector, which is used to determine if special | ||
| action needs to eb taken due to the system being overloaded or saturated. This section is described in more detail in the section [Saturation Detector configuration](#saturation-detector-configuration) | ||
| The data section configures the data layer, which is used to gather metrics and other data used in making scheduling decisions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| The data section configures the data layer, which is used to gather metrics and other data used in making scheduling decisions. | |
| The `data` section configures the data layer, which is used to gather information (such as metrics) used in making scheduling decisions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, may want to use backticks to mark section names explicitly (i.e., data and not data)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
| ## Data Layer configuration | ||
|
|
||
| The Data Layer collects metrics and other data used in scheduling decisions made by the various configured | ||
| filters and plugins. The exact data collected varies by the DataSource and Extractors configured. The basic ones |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
filters is specific to scheduling but plugins is generic. Maybe use scheduling plugins as the term?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
| filters and plugins. The exact data collected varies by the DataSource and Extractors configured. The basic ones | ||
| collect Prometheus metrics from the Model Servers in the InferencePool. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| filters and plugins. The exact data collected varies by the DataSource and Extractors configured. The basic ones | |
| collect Prometheus metrics from the Model Servers in the InferencePool. | |
| filters and plugins. The exact data collected varies by the DataSource and Extractors configured. The baseline | |
| provided in GAIE collect Prometheus metrics from the Model Servers in the InferencePool. |
nit: do we want to reference MSP doc here? Not required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. If at all it should be mentioned in more detailed Datalayer documentation
| filters and plugins. The exact data collected varies by the DataSource and Extractors configured. The basic ones | ||
| collect Prometheus metrics from the Model Servers in the InferencePool. | ||
|
|
||
| The Data Layer is configured via the data section of the overall configuration. It has the following form: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| The Data Layer is configured via the data section of the overall configuration. It has the following form: | |
| The Data Layer is configured via the `data` section of the overall configuration. It has the following form: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
| Each entry in the sources list has the following fields: | ||
|
|
||
| - *pluginRef* is a reference to the name of the plugin instance to be used. | ||
| - *extractors* specifies the list of the extractor plugin instances, by name, to be used with this DataSource. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
I find having a required pluginRef to name the data source but no pluginRef for extractors somewhat inconsistent. If we can name extractors directly, can't we do the same for datasource... Logically map[string][]string
|
/lgtm |
|
/hold |
|
/unhold |
|
/lgtm |
| return "{" + result + "}" | ||
| } | ||
|
|
||
| // DataLayerConfig contains the configuration of the V2 DataLayer feature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not this PR, but we need to figure out what we want to do with this config API. It's essentially a full fledged API, but not a CRD, and so is never 'applied' to k8s, and the control plane has no knowledge of it.
We essentially treat this just like a normal config file, but the yaml, and the way its structured in the code base makes it look like a CRD. I feel that if I was a newcomer, I would expect this file to be updatable and a part of the k8s ecosystem, which it is not.
Not a burning need, and again, not this PR. Just something to think about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally the configuration wasn't a pseudo CRD. @ahg-g requested that I use the K8S machinery to parse the YAML text.
This can be backed off if desired. We simply need to come to a decision.
| return "{" + result + "}" | ||
| } | ||
|
|
||
| // DataLayerConfig contains the configuration of the V2 DataLayer feature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
super nit: remove v2, I dont think we have any configuration of the v1 data layer, so once v1 is finished implementation, its the only data layer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
|
|
||
| func loadDataLayerConfig(rawDataConfig *configapi.DataLayerConfig, rawFeatureGates configapi.FeatureGates, handle plugins.Handle) (*datalayer.Config, error) { | ||
| featureGates := loadFeatureConfig(rawFeatureGates) | ||
| if !featureGates[datalayer.FeatureGate] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we return an error if the datalayer (or any feature) is configured with plugins but the feature gate is closed? A user may want to know about that early on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a check and an error.
e2227e9 to
8300077
Compare
|
New changes are detected. LGTM label has been removed. |
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
Signed-off-by: Shmuel Kallner <kallner@il.ibm.com>
2bc2edd to
78d915c
Compare
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR removes the need to configure the new V2 DataLayer from code. It extends the existing textual configuration enabling the configuration of DataSources and their respective Extractors.
Does this PR introduce a user-facing change?: