Skip to content

[v0.1 API Review] Grammatical fixes and TypedCondition creation/defaulting #186

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

Merged
merged 6 commits into from
Jan 16, 2025

Conversation

kfswain
Copy link
Collaborator

@kfswain kfswain commented Jan 10, 2025

This addresses comments:

3f971ca#r1907775587

3f971ca#r1907785698

3f971ca#r1907790075

and other smaller ones (can make the list exhaustive if needed but they are mostly grammatical or more detailed wording

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kfswain

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

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. approved Indicates a PR has been approved by an approver from all required OWNERS files. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 10, 2025
@kfswain
Copy link
Collaborator Author

kfswain commented Jan 10, 2025

CC: @candita

@kfswain kfswain mentioned this pull request Jan 10, 2025
@danehans
Copy link
Contributor

xref #190 for introducing the ResolvedRefs status condition.

Comment on lines 198 to 212
// This condition indicates if the model is ready to accept traffic, and if not, why.
//
// Possible reasons for this condition to be True are:
//
// * "Ready"
//
// Possible reasons for this condition to be False are:
//
// * "ModelNameInUse"
//
// Possible reasons for this condition to be Unknown are:
//
// * "Pending"
//
ModelConditionReady InferenceModelConditionType = "Ready"
Copy link
Contributor

Choose a reason for hiding this comment

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

The Gateway API community had some learning lessons with the Ready condition (xref). From the godocs:

// If used in the future, "Ready" will represent the final state where all configuration is confirmed good
// and has completely propagated to the data plane. That is, it is a guarantee that, as soon as something
// sees the Condition as true, then connections will be correctly routed immediately.

Should we start with the Programmed condition and reserve Ready until we can guarantee a model server is ready to accept connections when Ready: True?

Copy link
Member

Choose a reason for hiding this comment

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

+1, agree on reusing Programmed or Accepted here

Copy link
Contributor

Choose a reason for hiding this comment

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

+1; I actually think we should start with Accepted since ModelNameInUse is more about that the InferenceModel is not accepted, and less about the inability to program it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Agreed with all comments. Accepted seems the most appropriate for the given intent

// Details about naming conflict resolution are on the ModelName field itself.
ModelReasonNameInUse InferenceModelConditionReason = "ModelNameInUse"

// This reason is the initial state, and indicates that the controller has not yet reconciled the InferenceModel.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we expect that an InferenceModel status to revert back to Pending from Ready? or is that left to the implementation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I doubt it would ever go from Accepted back to Pending. But leaving it up to the implementation is fine with me

Comment on lines 198 to 212
// This condition indicates if the model is ready to accept traffic, and if not, why.
//
// Possible reasons for this condition to be True are:
//
// * "Ready"
//
// Possible reasons for this condition to be False are:
//
// * "ModelNameInUse"
//
// Possible reasons for this condition to be Unknown are:
//
// * "Pending"
//
ModelConditionReady InferenceModelConditionType = "Ready"
Copy link
Contributor

Choose a reason for hiding this comment

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

+1; I actually think we should start with Accepted since ModelNameInUse is more about that the InferenceModel is not accepted, and less about the inability to program it.

Copy link
Member

@robscott robscott left a comment

Choose a reason for hiding this comment

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

Thanks @kfswain !

Comment on lines 198 to 212
// This condition indicates if the model is ready to accept traffic, and if not, why.
//
// Possible reasons for this condition to be True are:
//
// * "Ready"
//
// Possible reasons for this condition to be False are:
//
// * "ModelNameInUse"
//
// Possible reasons for this condition to be Unknown are:
//
// * "Pending"
//
ModelConditionReady InferenceModelConditionType = "Ready"
Copy link
Member

Choose a reason for hiding this comment

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

+1, agree on reusing Programmed or Accepted here

Copy link
Member

@robscott robscott left a comment

Choose a reason for hiding this comment

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

Thanks @kfswain !

@k8s-ci-robot k8s-ci-robot added do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 15, 2025
Copy link

netlify bot commented Jan 15, 2025

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

Name Link
🔨 Latest commit 4fb9e22
🔍 Latest deploy log https://app.netlify.com/sites/gateway-api-inference-extension/deploys/6788343a67fbc800086cbf1d
😎 Deploy Preview https://deploy-preview-186--gateway-api-inference-extension.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Jan 15, 2025
//
// * "Pending"
//
ModelConditionReady InferenceModelConditionType = "Accepted"
Copy link
Contributor

Choose a reason for hiding this comment

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

update variable names too

@ahg-g
Copy link
Contributor

ahg-g commented Jan 15, 2025

/lgtm

/hold

holding in case others have more suggestions

@k8s-ci-robot k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm "Looks good to me", indicates that a PR is ready to be merged. labels Jan 15, 2025
@ahg-g
Copy link
Contributor

ahg-g commented Jan 16, 2025

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 16, 2025
@k8s-ci-robot k8s-ci-robot merged commit 6a4b025 into kubernetes-sigs:main Jan 16, 2025
8 checks passed
@kfswain kfswain deleted the api-feedback-1 branch January 23, 2025 21:04
@danehans danehans added this to the v0.1.0-rc.1 milestone Jan 30, 2025
kfswain added a commit to kfswain/llm-instance-gateway that referenced this pull request Apr 29, 2025
…lting (kubernetes-sigs#186)

* Feedback updates + code gen

* Adding explanations for condition reasons

* typo fix

* Updating Condition Type

* generated manifests

* var name update
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants