Skip to content
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

Merged
merged 47 commits into from Aug 12, 2020
Merged

InferenceService v1beta1 API #991

merged 47 commits into from Aug 12, 2020

Conversation

yuzisun
Copy link
Member

@yuzisun yuzisun commented Aug 3, 2020

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.

  1. v1beta1 inference service api should be good for review.
  2. v1alpha1 inference router api is for preview, mainly focused on the pipeline spec.

Release note:


@kubeflow-bot
Copy link

This change is Reviewable

@google-cla
Copy link

google-cla bot commented Aug 3, 2020

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@google-cla
Copy link

google-cla bot commented Aug 3, 2020

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@ellistarn
Copy link
Contributor

Any way to separate some of these types to review them separately in a smaller PR?

@yuzisun
Copy link
Member Author

yuzisun commented Aug 3, 2020

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.

Makefile Outdated Show resolved Hide resolved
@@ -20,8 +20,7 @@ import (
"k8s.io/klog"
)

// +k8s:openapi-gen=false
// +k8s:deepcopy-gen=false
// +kubebuilder:object:generate=false
Copy link
Contributor

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yaml.DisallowUnknownFields

Copy link
Member Author

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?

Copy link
Contributor

@ellistarn ellistarn Aug 8, 2020

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.

Copy link
Member Author

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

Copy link
Contributor

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.
Copy link
Contributor

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"`
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

@ellistarn ellistarn Aug 8, 2020

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"`
Copy link
Contributor

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?

Copy link
Member Author

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.

@njhill
Copy link
Contributor

njhill commented Aug 5, 2020

Just a note that I would like to review this but may take a bit of time to get through it!

@google-cla
Copy link

google-cla bot commented Aug 8, 2020

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

1 similar comment
@google-cla
Copy link

google-cla bot commented Aug 8, 2020

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@yuzisun yuzisun changed the title InferenceService v1beta1 API and InferenceRouter v1alpha1 preview InferenceService v1beta1 API Aug 8, 2020
@google-cla
Copy link

google-cla bot commented Aug 8, 2020

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

name: "tensorflow-canary"
spec:
predictor:
canaryTrafficPercent: 20
Copy link
Contributor

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"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love to see this.

@google-cla
Copy link

google-cla bot commented Aug 11, 2020

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@wengyao04
Copy link
Contributor

@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
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

@ellistarn ellistarn left a 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 {
Copy link
Contributor

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 {
Copy link
Contributor

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

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@yuzisun yuzisun merged commit e133d7f into kserve:master Aug 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants