-
Notifications
You must be signed in to change notification settings - Fork 102
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
Fix updating invalid Instance parameters #1441
Conversation
Summary: in the past we've allowed updating Instance with parameters that are missing in the corresponding OV (since there were no way to forbid this in the absence of an admission controller). Now that we have instance admission controller in place, we can fix this behavior. Fixes #1411 Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
3cb6f37
to
7506140
Compare
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.
LGTM!
See my comments on handling added parameters on upgrades. Although this is handled in the existing code, this could be clearer by handling this by calling GetParamDefinitions
for added and removed parameters separately.
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
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.
lgtm
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.
A few comments inline.
Also, now that we have typed parameters, I think we should somehow attempt verify the type of the passed parameter. Something simple like attempting an unmarshall of the parameter according to type would do the trick.
@@ -299,15 +299,15 @@ func TestValidateUpdate(t *testing.T) { | |||
wantErr: true, | |||
}, | |||
{ | |||
name: "parameter update triggering a non-existing OV plan IS allowed but will NOT trigger a plan", | |||
name: "parameter update triggering a non-existing OV plan IS NOT allowed", |
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 think this change of behaviour deserves at least a mention in the PR description, if not title.
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 mentioned in the PR description and somewhat vaguely in the PR title. Do you have a better title suggestion that doesn't exceed 60 characters?
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 test claims to be about "non-existent plans" while the PR title/description only seems to mention non-existent parameters. To me these are two different things.
See also #1268 w.r.t the former.
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.
You're right, plan description is misleading, it's the parameter existence that is being checked. Fixed the description.
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.
...and also added a test for the missing plan 👍
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
Signed-off-by: Aleksey Dukhovniy <alex.dukhovniy@googlemail.com>
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.
🚢
Summary:
in the past, we've allowed updating Instance with parameters that are missing in the corresponding OV (since there was no way to forbid this in the absence of an admission controller). Now that we have the instance admission controller in place, we can fix this behavior.
Fixes #1411
Signed-off-by: Aleksey Dukhovniy alex.dukhovniy@googlemail.com