-
Notifications
You must be signed in to change notification settings - Fork 639
🐛 add marketType field validation #5374
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
|
Hi @athiruma. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/ok-to-test |
5c51cdd to
8e8d4be
Compare
|
@JoelSpeed ptal 👋 |
|
Changes look ok, have we considered if we should use CEL validations rather than webhooks for this kind of validation moving forward? |
Im not aware of CEL, may I'll look into it. |
|
You can add a marker, something along the lines of |
|
@athiruma are you able to switch to the CEL validation for this? |
8e8d4be to
0e747a4
Compare
966755e to
95dfbed
Compare
api/v1beta2/awsmachine_types.go
Outdated
| // If this value is selected, CapacityReservationID must be specified to identify the target reservation. | ||
| // If marketType is not specified and spotMarketOptions is provided, the marketType defaults to "Spot". | ||
| // +optional | ||
| // +kubebuilder:validation:XValidation:rule="!has(self.capacityReservationID) || !has(self.marketType) || self.marketType != 'Spot'",message="capacityReservationID may not be set when marketType is Spot" |
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 must be added to the parent struct, and not this field, as "self" in the rule will apply to the field if you apply it here, or the parent struct if you apply it to the parent struct
|
/retest-required |
|
/retest |
|
@athiruma we don't do vendoring here in upstream CAPA, could you drop the |
317b8f1 to
3f4c874
Compare
|
/retest-required |
|
You could try to rebase to see if apidiff gets fixed |
|
@athiruma looks like units need updating after the error message changes. |
022d46f to
8a46c2b
Compare
|
@damdo ptal! |
damdo
left a comment
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.
Looks good, last little change to make it more consistent, then I am happy with it!
Thanks a lot
8a46c2b to
22650ee
Compare
|
/label tide/merge-method-squash |
damdo
left a comment
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.
|
|
||
| // AWSMachineSpec defines the desired state of an Amazon EC2 instance. | ||
| // +kubebuilder:validation:XValidation:rule="!has(self.capacityReservationId) || !has(self.marketType) || self.marketType != 'Spot'",message="capacityReservationId may not be set when marketType is Spot" | ||
| // +kubebuilder:validation:XValidation:rule="!has(self.capacityReservationId) || !has(self.spotMarketOptions)",message="capacityReservationId cannot be set when spotMarketOptions is specified" |
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'll need to check the docs (but maybe @JoelSpeed knows), if we are tightening the validation rules is this considered a breaking behavioural change? Guess it depends on if it breaks currently.
@athiruma - whats the current behaviour if i set capacityReservationId and specify spot? Does it currently error in this situation?
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.
Yes, it will raise an error.
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.
If the capacity reservation ID field has already shipped within a release, then yes, this could cause an issue for users who have already started using the field
Given that EC2 will reject creating machines with this configuration already, we are bringing the validation earlier here realistically, and ratcheting should also help with invalid combinations if folks are updating the objects.
I'm inclined to say this is likely to be fairly safe depending on how long ago this shipped
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 has shipped in CAPA v2.8.1 a couple of weeks ago.
I think if we backport it to v2.8.z and then release it in v2.9.0 we should be fine right?
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.
Sounds like we are all good then.
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.
Yeah considering this would already fail anyway at a later stage.
Happy to approve then @richardcase ?
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: richardcase 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 |
* Add spotMarketRequest on marketType spot * Add CEL validation * update vendor files * added validation * Updated the comments
|
/cherry-pick release-2.8 |
|
@damdo: Failed to get PR patch from GitHub. This PR will need to be manually cherrypicked. Error messagestatus code 422 not one of [200], body: {"message":"The patch is taking too long to generate.","documentation_url":"https://docs.github.com/rest/pulls/pulls#get-a-pull-request","status":"422"}In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
* Add spotMarketRequest on marketType spot * Add CEL validation * update vendor files * added validation * Updated the comments
|
/cherry-pick release-2.8 |
|
@damdo: Failed to get PR patch from GitHub. This PR will need to be manually cherrypicked. Error messagestatus code 422 not one of [200], body: {"message":"The patch is taking too long to generate.","documentation_url":"https://docs.github.com/rest/pulls/pulls#get-a-pull-request","status":"422"}In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
* Add spotMarketRequest on marketType spot * Add CEL validation * update vendor files * added validation * Updated the comments
* Add spotMarketRequest on marketType spot * Add CEL validation * update vendor files * added validation * Updated the comments
What type of PR is this?
What this PR does / why we need it:
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:
Checklist:
Release note: