-
Notifications
You must be signed in to change notification settings - Fork 975
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 PodSecurityPolicy
removal note in docs
#2241
Conversation
Perhaps we should also set a |
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 to what @jrhouston said. We should to surface the deprecation to users at runtime. Ideally we also gate the use of this resource on the API server version. We have precedent of that in some other resources.
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 add my 5 cents here.
This is not the only resource that got deprecated in this or that Kubernetes version, we have a few of them. I would vote for a more standardized approach. We could have a section in our documentation on top that mentions the target Kubernetes release of the resource that gets deprecated. Usually, this information is available a few releases in advance. It also would be nice to mention whether there is a successor resource in our provide if applicable, so practitioners can plan migration ahead. And this all should be synchronized with the resources warning messages.
I think it could be a part of the documentation improvement epic, along with the kind and API versions that the resource implements.
Follow up discussion: instead of
|
Description
Fixes #2234
Acceptance tests
Output from acceptance testing:
Release Note
Release note for CHANGELOG:
References
Community Note