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

Make selector immutable for v1beta2 deployment, replicaset and daemonset prior update #50719

Merged
merged 1 commit into from
Sep 1, 2017

Conversation

crimsonfaith91
Copy link
Contributor

@crimsonfaith91 crimsonfaith91 commented Aug 15, 2017

What this PR does / why we need it:
This PR ensures controller selector is immutable for deployment and replicaset prior update by ignoring any change to Spec.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #50808

Special notes for your reviewer:
This will be a breaking change.

Release note:

For Deployment, ReplicaSet, and DaemonSet, selectors are now immutable when updating via the new `apps/v1beta2` API. For backward compatibility, selectors can still be changed when updating via `apps/v1beta1` or `extensions/v1beta1`.

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Aug 15, 2017
@k8s-github-robot k8s-github-robot added size/S Denotes a PR that changes 10-29 lines, ignoring generated files. release-note Denotes a PR that will be considered when it comes time to generate release notes. labels Aug 15, 2017
@crimsonfaith91 crimsonfaith91 changed the title Make selector immutable for deployment and replicaset prior update Make selector immutable for v1beta2 deployment and replicaset prior update Aug 15, 2017
// We assume API version is not v1beta2 if no RequestInfo is found
requestInfo, found := genericapirequest.RequestInfoFrom(ctx)
if found && requestInfo.APIVersion == "v1beta2" {
newDeployment.Spec = oldDeployment.Spec
Copy link
Contributor Author

@crimsonfaith91 crimsonfaith91 Aug 15, 2017

Choose a reason for hiding this comment

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

@kow3ns @enisoc Perhaps newDeployment.Spec.Selector = oldDeployment.Spec.Selector is better. Any thought?

// update is not allowed to set spec for v1beta2
// We assume API version is not v1beta2 if no RequestInfo is found
requestInfo, found := genericapirequest.RequestInfoFrom(ctx)
if found && requestInfo.APIVersion == "v1beta2" {
Copy link
Contributor Author

@crimsonfaith91 crimsonfaith91 Aug 15, 2017

Choose a reason for hiding this comment

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

For now, it affects only v1beta2 API version. In future, we may need to change it to v1 or have a range like greater than v1.

Copy link
Member

@kow3ns kow3ns left a comment

Choose a reason for hiding this comment

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

You can't clear the entire spec, this disallows all relevant changes to the API object. You might be able to clear the selector change. Is this the method that you discussed with @erictune?

@crimsonfaith91
Copy link
Contributor Author

crimsonfaith91 commented Aug 16, 2017

@kow3ns Yes, it is one of the ways suggested by Eric. I am not sure we should ignore all changes to Spec (this is what StatusUpdate does), and wish to get feedback before writing unit tests. I also suggested newDeployment.Spec.Selector = oldDeployment.Spec.Selector in another comment.

// update is not allowed to set Spec.Selector for v1beta2
// we assume it is not v1beta2 if no API group and/or version is found in RequestInfo
// TODO(#50791): after v1beta1 is retired, move selector immutability check to validation codes
requestInfo, found := genericapirequest.RequestInfoFrom(ctx)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@erictune @kow3ns As discussed by person, i added a TODO for moving the check to validation codes after v1beta1 retires, and included the API group in the condition.

@crimsonfaith91 crimsonfaith91 changed the title Make selector immutable for v1beta2 deployment and replicaset prior update Make selector immutable for v1beta2 deployment, replicaset and daemonset prior update Aug 16, 2017
@k8s-github-robot k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Aug 17, 2017
if err != nil {
t.Errorf("Unexpected error for url: %s %v", test.url, err)
}
if !apiRequestInfo.IsResourceRequest {
Copy link
Contributor Author

@crimsonfaith91 crimsonfaith91 Aug 17, 2017

Choose a reason for hiding this comment

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

@kow3ns
After writing the unit test, i think we can leave out the API group when determining whether to ignore changes to Spec.Selector. The main reason is due to how RequestInfo works.

IsResourceRequest returns true for requests to API resources, like /api/v1/..., and false for non-resource endpoints like /api, /healthz, and /swaggerapi. In other words, something like /api/v1beta2/... works, but not /api/apps/v1beta2/... (additional apps after api) or /apps/v1beta2/... (do not start with api).

Furthermore, we will have the silent ignore for v1 in future, which will be /api/v1/... that works perfectly with how RequestInfo works. Moreover, v1beta2 only exists for apps group, which does not justify checking the API group.

WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

These controllers never existed in the groupless /api/ prefix, so your test shouldn't expect those inputs to work. Specifically, you want to make sure that /apis/extensions/v1beta1 allows mutation, and /apis/apps/v1beta2 does not. If we decide to plan ahead for /apis/apps/v1 you could test for that too, but I don't know if that's decided yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@enisoc Good point! Thanks for the clarification. I will test for /apis/extensions/v1beta1 and /apis/apps/v1beta2.

// we assume it is not v1beta2 if no API version is found in RequestInfo
// TODO(#50791): after v1beta1 is retired, move selector immutability check to validation codes
requestInfo, found := genericapirequest.RequestInfoFrom(ctx)
if found && requestInfo.APIVersion == "v1beta2" {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Refer this comment for why checking API group may be unnecessary.

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 30, 2017
@liggitt
Copy link
Member

liggitt commented Aug 30, 2017

this is definitely worth a release note

@enisoc enisoc added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesn't merit a release note. labels Aug 30, 2017
@k8s-github-robot k8s-github-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 30, 2017
@liggitt
Copy link
Member

liggitt commented Aug 30, 2017

/lgtm
though I am not an approver on pkg/registry

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 30, 2017
@smarterclayton
Copy link
Contributor

/approve

Based on discussion in linked issue and general agreement that we can potentially relax / add better changes in the future.

@k8s-github-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: crimsonfaith91, enisoc, liggitt, smarterclayton

Associated issue: 50808

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 31, 2017
@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 50719, 51216, 50212, 51408, 51381)

@k8s-github-robot k8s-github-robot merged commit 9a3dfbc into kubernetes:master Sep 1, 2017
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. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Controller selectors should be immutable after creation