CC @kubernetes/sig-storage-misc
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.![]()
This is my WIP:
Is this the right tone/scope/style?
Hey, I'm writing the FAQ section based on things that were confusing during writing the previous sections. I'm working on a question titled "How do cloud provider volume plugins figure out what mount device (e.g., /dev/sdc) a newly-attached volume will appear as?"
It seems that most of them query their respective APIs and are able to come up with some kind of block device mapping either directly or by something like LUN. What's the use of predicting the next available device?
Okay a new look tells me that it's prevented here:
This will make it to the implementor's guide.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
/remove-lifecycle stale
/lifecycle frozen
New plugins no longer being added/written. Please add new storage backends to Kubernetes through CSI: https://kubernetes-csi.github.io/docs/developing.html
/close
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
Closed #13753.
@davidz627: Closing this issue.
In response to this:
New plugins no longer being added/written. Please add new storage backends to Kubernetes through CSI: https://kubernetes-csi.github.io/docs/developing.html
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.