-
Notifications
You must be signed in to change notification settings - Fork 89
[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
Conversation
[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 |
CC: @candita |
xref #190 for introducing the |
api/v1alpha1/inferencemodel_types.go
Outdated
// 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" |
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 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 astrue
, 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
?
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.
+1, agree on reusing Programmed
or Accepted
here
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.
+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.
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.
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. |
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.
Do we expect that an InferenceModel status to revert back to Pending
from Ready
? or is that left to the implementation?
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 doubt it would ever go from Accepted
back to Pending
. But leaving it up to the implementation is fine with me
api/v1alpha1/inferencemodel_types.go
Outdated
// 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" |
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.
+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.
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.
Thanks @kfswain !
api/v1alpha1/inferencemodel_types.go
Outdated
// 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" |
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.
+1, agree on reusing Programmed
or Accepted
here
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.
Thanks @kfswain !
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
ea47745
to
9942311
Compare
api/v1alpha1/inferencemodel_types.go
Outdated
// | ||
// * "Pending" | ||
// | ||
ModelConditionReady InferenceModelConditionType = "Accepted" |
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.
update variable names too
/lgtm /hold holding in case others have more suggestions |
/hold cancel |
…lting (kubernetes-sigs#186) * Feedback updates + code gen * Adding explanations for condition reasons * typo fix * Updating Condition Type * generated manifests * var name update
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