Notice of deprecation for recycler. #36760
Conversation
childsb
added
the
sig/storage
k8s-github-robot
added
size/M
|
Jenkins verification failed for commit 9a67951. Full PR test history. The magic incantation to run this job again is |
saad-ali
added
release-note
k8s-ci-robot
added
the
cncf-cla: yes
|
/lgtm CC @kubernetes/sig-storage Please fix broken munge docs: |
k8s-ci-robot
added
the
lgtm
|
We should also update the official k8s documentation to indicate that the recycler policy will be deprecated and should not be used--those docs will be much more user visible. |
| @@ -0,0 +1,32 @@ | |||
| ## Deprecation of Persistent Volume Recycler Behavior | |||
| The function of the persistent volume recycler will change in future kubernetes releases. The current implementation will remain and function as is for the short term but is expected to be removed or replaced in future releases. | |||
There was a problem hiding this comment.
We can't really remove it. It's part of the v1 API.
|
|
||
| Additionally, delete/create is an admin control plane operation and the node hosting the recycle POD will need network access to the storage control plane and the admin credentials. Its desirable to isolate storage control plan from the user network for security. | ||
|
|
||
| ## Rational |
| ## Timeline | ||
|
|
||
| * Kube 1.5 : Notice of deprecation | ||
| * Kube 1.5 + 1 year : Remove old recycler API |
There was a problem hiding this comment.
This is, unfortunately, not my interpretation of the API compat guarantees. I think we have to keep this for all v1 installations. When we launch API v2, we can remove this from v2 after now + 1 year (which is likely to happen before v2) launches.
@bgrant0607 - have we any precedent for API deprecations yet?
There was a problem hiding this comment.
@thockin pod.spec.serviceAccount has been deprecated since 1.0, but has not been removed. node.status.phase has been deprecated and is not populated, but has not been removed.
Technically, we're not supposed to remove fields in the current API version. As I recall, we had planned to remove deprecated fields in the next major API version:
https://github.com/kubernetes/kubernetes/blob/master/docs/design/versioning.md
However, I could be persuaded that 1 year beyond deprecation is sufficient, assuming that we add fine-grain versioning (#34508).
There was a problem hiding this comment.
Thanks, Brian - that was my comprehension, too.
If we add finer-grained API versioning, I could likewise be convinced. Absent that, we can mark this as deprecated but we can't remove it. Removing the functionality but leaving the API is pretty sketchy, even.
There was a problem hiding this comment.
@childsb Can we change the language here to indicate that this will be removed from the next API version, but will remain in the v1 API
| @@ -0,0 +1,32 @@ | |||
| ## Deprecation of Persistent Volume Recycler Behavior | |||
There was a problem hiding this comment.
I don't know where this file should live, but the code is probably not the right place. Maybe in the API docs repo, linked from the docs about the feature?
There was a problem hiding this comment.
@kubernetes/docs I know the release is imminent, but I want to put this into the queue. Do we have a doc or index of docs that cover deprecated features?
…e expected change (delete then recreate) since its up for debate.
k8s-github-robot
removed
the
lgtm
|
I updated with the concerns in the PR except for 'where should it live'. If this should move, let me know where. If we dont know i suggest we merge as is for 1.5 and defer to cunninghams law. |
|
@saad-ali ping |
| **USE RECYCLE API AT YOUR OWN RISK AS IT MAY BE REMOVED OR SIGNIFICANTLY CHANGED IN FUTURE KUBERNETES RELEASES**. | ||
|
|
||
| ## Problem Scenarios | ||
| **Scenario 1**: User attaches a volume to their POD and is assigned a suplimental group but their default group is some other group. New files are created as the default group and for the recycler to remove them it would have to run as the default group. The scenario is similar and problimatic for chown'ed and chgroup'ed files. The recycler has no way to determine at launch which group to run as to remove every file on a recycled volume. |
There was a problem hiding this comment.
spelling - supplemental and problematic
| **Scenario 2**: Malicious user writes a POD that uses debugfs to inspect attached volumes for previously deleted files. Malicious user would gain access to "recycled" files from other users. | ||
|
|
||
| To work around either of these scenarios kubernetes will need to delete the partition on the storage volume and re-create. In the current architecture the volume attached to the recycler is unavialble for deletion as its in use. | ||
|
|
|
I spoke with @devin-donnelly on this, and he's going to find a place for us to register and store deprecation notices such as this. @mbohlool we should probably consider another annotation on fields and structs to indicate that they are deprecated, but we need to spec not just that it is deprecated, but also where to find more information, and maybe when or what what API version it will stop working in. |
|
I agree we need something nicer for deprecation notices, for now does anyone mind if I just ping the 1.5 known issues accumulator (#37134) and use that as my reference point? |
|
You want to add this to the 1.5 accumulator? I guess..
…On Wed, Nov 30, 2016 at 1:46 PM, Aaron Crickenberger < ***@***.***> wrote:
I agree we need something nicer for deprecation notices, for now does
anyone mind if I just ping the 1.5 known issues accumulator (#37134
<#37134>) and use that as
my reference point?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36760 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVOcl5EhG_OZkxvCMorXairIJIhTXks5rDe6ngaJpZM4KxnZP>
.
|
We should get that set up within the 1.5 timeframe (i.e. <1 week). |
|
@childsb looks like this missed the boat. Move the milestone please if appropriate? |
|
Note that the 1.5.0 release notes are currently pointing to this PR for "notice of deprecation for recycler". Let's find a permanent place for this notice and update the release notes link to point to that. |
|
OK, we have a new home for deprecation notices - want to be the first?
clone http://github.com/kubernetes/kubernetes.github.io
add docs/deprecated/ dir
add an index.md file and link to your own file
Then we can debate the style as well as the substance!
…On Thu, Dec 15, 2016 at 2:33 PM, Saad Ali ***@***.***> wrote:
Note that the 1.5.0 release notes are currently pointing to
<https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#v150>
this PR for "notice of deprecation for recycler". Let's find a permanent
place for this notice and update the release notes link to point to that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36760 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVCtyyQMQLCRX9j4_M2CiUi8VaCbGks5rIcBTgaJpZM4KxnZP>
.
|
|
[APPROVALNOTIFIER] Needs approval from an approver in each of these OWNERS Files: We suggest the following people: |
k8s-github-robot
added
the
approved
|
This PR hasn't been active in 90 days. Closing this PR. Please reopen if you would like to work towards merging this change, if/when the PR is ready for the next round of review. cc @childsb @saad-ali @thockin You can add 'keep-open' label to prevent this from happening again, or add a comment to keep it open another 90 days |
This PR is to give notice to user that the recycler function will be removed.
The recycler is difficult to support, breaks in many scenarios and the use cases its covering are replaced with dynamic provision and deletion of volumes.
This change is