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

Secret and ConfigMap volume do not report unique volume name correctly #29555

Closed
pmorie opened this issue Jul 25, 2016 · 6 comments
Closed

Secret and ConfigMap volume do not report unique volume name correctly #29555

pmorie opened this issue Jul 25, 2016 · 6 comments
Labels
priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/storage Categorizes an issue or PR as relevant to SIG Storage.
Milestone

Comments

@pmorie
Copy link
Member

pmorie commented Jul 25, 2016

The secret and configmap volume name do not report the unique volume name correctly. They should both incorporate the namespace of the secret/configmap into the value returned so that the volume manager will correctly handle their mount/unmounts when different namespaces contain secrets or configmaps with the same name.

cc @saad-ali

Related: #28616

@matchstick matchstick added this to the v1.3 milestone Jul 25, 2016
@matchstick matchstick added sig/storage Categorizes an issue or PR as relevant to SIG Storage. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels Jul 25, 2016
@asalkeld
Copy link

asalkeld commented Jul 26, 2016

It seem to me like the namespace is missing from these VolumeSources.

As an alternative we would have to pass namespace into GetVolumeName() or just prefix the result (for all plugins), (this seems tricky as the calling points don't seem to have any reference to the pod).

@asalkeld
Copy link

Also see #29582.

@pmorie
Copy link
Member Author

pmorie commented Jul 27, 2016

@asalkeld It's not just the namespace -- for example, if you reference the same configmap or secret in two different volumes in the same pod, one of them will never be mounted.

@asalkeld
Copy link

Need this change https://github.com/kubernetes/kubernetes/pull/28534/files in secrets too.

@saad-ali
Copy link
Member

@asalkeld With @pmorie changes in PR ##29673 that will no longer be needed.

k8s-github-robot pushed a commit that referenced this issue Jul 28, 2016
Automatic merge from submit-queue

Fix mount collision timeout issue

Short- or medium-term workaround for #29555.  The root issue being fixed here is that the recent attach/detach work in the kubelet uses a unique volume name as a key that tracks the work that has to be done for each volume in a pod to attach/mount/umount/detach.  However, the non-attachable volume plugins do not report unique names for themselves, which causes collisions when a single secret or configmap is mounted multiple times in a pod.

This is still a WIP -- I need to add a couple E2E tests that ensure that tests break in the future if there is a regression -- but posting for early review.

cc @kubernetes/sig-storage 

Ultimately, I would like to refine this a bit further.  A couple things I would like to change:

1.  `GetUniqueVolumeName` should be a property ONLY of attachable volumes
2.  I would like to see the kubelet apparatus for attach/mount/umount/detach handle non-attachable volumes specifically to avoid things like the `WaitForControllerAttach` call that has to be done for those volume types now
@saad-ali
Copy link
Member

Closed with #29673

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/storage Categorizes an issue or PR as relevant to SIG Storage.
Projects
None yet
Development

No branches or pull requests

4 participants