-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Add PSP to the deprecation guide #26629
Conversation
@reylejano missed your comment before pushing this - how do you want to handle it? This information seems relevant prior to v1.21 being released, so I'd vote to keep it on the main branch. |
Deploy preview for kubernetes-io-master-staging ready! Built with commit ce2e5f8 https://deploy-preview-26629--kubernetes-io-master-staging.netlify.app |
@@ -49,6 +49,13 @@ RuntimeClass in the **node.k8s.io/v1beta1** API version will no longer be served | |||
* All existing persisted objects are accessible via the new API | |||
* No notable changes | |||
|
|||
#### PodSecurityPolicy {#psp-v125} |
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.
my initial version kept this page limited to things with clear replacements. I was going to see what shook out for PSP this release, and if cronjob graduates to v1 as expected in 1.21, update this section for both of them after that.
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.
also, PSP deprecation is getting released with 1.21, so I'd hold this at least until 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.
I'm OK with merging this into the live website before v1.21 released, provided that:
- the deprecation in v1.21 is planned out, including how we communicate it
- we are confident beyond any reasonable doubt of the deprecation timeline, we are committing ourselves to make exactly the changes we're documenting here
- we make this update in tandem with the broader piece about communiction
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.
See PR #27369, Add blog post describing PSP deprecation and next steps.
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.
(now merged)
|
||
The **extensions/v1beta1** API version of PodSecurityPolicy is no longer served as of v1.16. | ||
|
||
* Migrate manifests and API client to use the **policy/v1beta1** API version, available since v1.10. |
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.
* Migrate manifests and API client to use the **policy/v1beta1** API version, available since v1.10. | |
* Migrate manifests and API clients to use the **policy/v1beta1** API version, available since v1.10. |
The **extensions/v1beta1** API version of PodSecurityPolicy is no longer served as of v1.16. | ||
|
||
* Migrate manifests and API client to use the **policy/v1beta1** API version, available since v1.10. | ||
* Note that the **policy/v1beta1** API version of PodSecurityPolicy will be removed in v1.25. |
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.
* Note that the **policy/v1beta1** API version of PodSecurityPolicy will be removed in v1.25. | |
* Note that the **policy/v1beta1** API version of PodSecurityPolicy is also deprecated and will be removed in v1.25. |
@@ -49,6 +49,13 @@ RuntimeClass in the **node.k8s.io/v1beta1** API version will no longer be served | |||
* All existing persisted objects are accessible via the new API | |||
* No notable changes | |||
|
|||
#### PodSecurityPolicy {#psp-v125} | |||
|
|||
PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. |
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.
PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. | |
The **policy/v1beta1** API version of PodSecurityPolicy will no longer be served in v1.25, and the PodSecurityPolicy admission plugin will be removed. |
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.
Would be good to add this, but I don't see it blocking a merge.
|
||
PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. | ||
|
||
PodSecurityPolicy replacements are still under discussion, but current use can be migrated to |
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 would avoid putting uncertain future-looking statements in this doc
PodSecurityPolicy replacements are still under discussion, but current use can be migrated to | |
Current use can be migrated to |
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.
We can link to the blog article from #27369, which I believe is due to merge and publish before the v1.21 release. Usually we don't link to blog articles for information about features but in this case I (confidently) think that's a good idea.
/hold until consensus on adding this to cc @palnabarun |
|
||
PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. | ||
|
||
PodSecurityPolicy replacements are still under discussion, but current use can be migrated to |
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.
👋 @tallclair .
I'm a bit surprised that this page includes information about future feature deprecations (about 1 yr away?).
nit: PodSecurityPolicy replacements are still under discussion; however, you can migrate current PodSecurityPolicy resources to ...
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 ones already included in the page in master
are current deprecations (if you kubectl get
those resources on a 1.20 API server, you get a message that they are deprecated, when they'll be removed, and what you should switch to using)
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.
current deprecations
makes sense to me
We could merge this change at the same time as the deprecation announcement.
SInce PSP deprecation is targeted 1.21, please consider submit this to the dev-1.21 branch. |
/milestone 1.21 |
@annajung I was suggesting this going into dev-1.21 branch because PSP is not deprecated in 1.20 yet. Considering that the target page already contains some future predicting contents, maybe we can lift the hold on this? |
I intentionally limited this page to items already announced as deprecated in a released version, which had an unequivocal "switch to use ____" call to action. Neither of those is yet true for PSP, so I wouldn't merge this to master yet. |
@liggitt @tallclair How about submitting this PR to the |
/lgtm |
LGTM label has been added. Git tree hash: c6ccb356f9965f6eaf628f55cdd7b7d52af3b580
|
Not unholding, but I recommend that whoever approves this does also unhold it. |
Hi @tallclair , what do you think of the suggestion of replacing |
I'm definitely happy to see this merge in even if there are nits. The commit in the PR right now could be polished, but is factually accurate enough to merge. |
/hold cancel |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: reylejano 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 |
See also #26581
/cc @deads2k