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
InferenceService v1beta1 API #991
Conversation
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
Any way to separate some of these types to review them separately in a smaller PR? |
yes will separate router out to separate PR once getting initial feedback, I want to have a single place for people to review both as an overall plan. |
@@ -20,8 +20,7 @@ import ( | |||
"k8s.io/klog" | |||
) | |||
|
|||
// +k8s:openapi-gen=false | |||
// +k8s:deepcopy-gen=false | |||
// +kubebuilder:object:generate=false |
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.
We should consider moving these interfaces into pkg/controller or somewhere else. The interfaces can be implemented by our types, but defined in a separate package to keep the generation simple.
func getExplainersConfigs(configMap *v1.ConfigMap) (*ExplainersConfig, error) { | ||
explainerConfig := &ExplainersConfig{} | ||
if data, ok := configMap.Data[ExplainerConfigKeyName]; ok { | ||
err := json.Unmarshal([]byte(data), &explainerConfig) |
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.
yaml.DisallowUnknownFields
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.
is this an unmarshal option?
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.
Yep. It tends to save users from headaches.
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.
does not look like that json unmarshal has this option
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.
// Pipeline defines a series of steps which are depending on previous step. | ||
// Only one root node is allowed and all other routes should specify dependencies with the consumes field. | ||
// The graph should form a valid DAG, no cycles are allowed, branches are allowed but they needs | ||
// be mutually exclusive. Each route on the pipeline can be either an InferenceService or an Inference Router. |
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.
Would we not allow any Destination (that supports the Data Plane)?
Headers map[string]*StringMatch `json:"headers,omitempty"` | ||
// This is a list of pipeline route names that should be executed before the current route. | ||
// The field is only valid for pipeline routing type | ||
Consumes []string `json:"consumes,omitempty"` |
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 sure I like the Consumes which is only used in Pipeline. Seems confusing. Maybe can rethink later?
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.
sure, open for ideas. The advantage is to reuse the same RouteSpec
and not introducing a new pipeline CRD, or you can think of other routes types all have an implicit consumes
for the root.
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 might simply remove Consumes, for now. I think the whole model of defining dependencies might be the wrong direction. It results in a really challenging to understand semantic. You can build dags as follows:
Pipeline1 { Pipeline 2, Pipeline 3}
Pipeline2 { Transformer1, InferenceService1 }
Pipeline3{ Transformer1, InferenceService2 }
That means each pipeline is itself linear, but can be constructed into more complex shapes.
// - `exact: "value"` for exact string match | ||
// - `prefix: "value"` for prefix-based match | ||
// - `regex: "value"` for regex-based match | ||
Headers map[string]*StringMatch `json:"headers,omitempty"` |
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.
Just focusing on headers with simple matches makes sense. I assume this is the "Condition" field of the Pipeline design v1?
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.
correct, I'd like to see how far header matching can go before we introduce more advanced matching.
Just a note that I would like to review this but may take a bit of time to get through it! |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
1 similar comment
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
name: "tensorflow-canary" | ||
spec: | ||
predictor: | ||
canaryTrafficPercent: 20 |
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.
This is sweet. I'm a huge fan.
|
||
// +kubebuilder:object:generate=false | ||
type TransformersConfig struct { | ||
Feast TransformerConfig `json:"feast,omitempty"` |
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.
Love to see this.
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
@googlebot I consent |
// Components interface is implemented by predictor, transformer and explainer | ||
// +kubebuilder:object:generate=false | ||
type Component interface { | ||
GetContainer(metadata metav1.ObjectMeta, containerConcurrency *int64, config *InferenceServicesConfig) *v1.Container |
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.
Now that containerconcurrency is in the component itself, do we need to pass this through?
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.
it is on the ComponentExtensionSpec
not the model server spec, ModelServerSpec maps to the container.
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.
Nice work! Let's get this submitted.
/approve
} | ||
|
||
// +kubebuilder:object:generate=false | ||
type InferenceServicesConfig struct { |
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.
very small nit: reading this again, I might call it InferenceServiceConfig, likewise for the method.
return nil | ||
} | ||
|
||
func (e *ExplainerSpec) GetExplainer() []Component { |
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 want to keep thrashing on this validation code, but it would probably be cleaner to have:
// Public method used to access explainer implementation. Uses returns getExplainers()[0]
GetExplainer() Component
// Private method used for internal validation
validateOnlyOneExplainer() error
// Private method used by validator and accessor
getExplainers() []Component
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ellistarn 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:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
InferenceService v1beta1 API and InferenceRouter v1alpha1 preview
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
I am putting inference service and router together mainly for folks to review with a wholistic perspective.
Release note: