-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Customizing host path for dynamically provisioned PersistentVolumes #6156
Conversation
Hi @nanikjava. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: nanikjava The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Can one of the admins verify this patch? |
Codecov Report
@@ Coverage Diff @@
## master #6156 +/- ##
=======================================
Coverage 38.38% 38.38%
=======================================
Files 123 123
Lines 8318 8318
=======================================
Hits 3193 3193
Misses 4706 4706
Partials 419 419 |
@@ -31,7 +31,7 @@ metadata: | |||
roleRef: | |||
apiGroup: rbac.authorization.k8s.io | |||
kind: ClusterRole | |||
name: system:persistent-volume-provisioner | |||
name: cluster-admin |
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.
This permission works fine but uncertain whether this is the correct one to use. Tried using the following
system:controller:expand-controller
system:controller:persistent-volume-binder
but it always complain permission issue either with persistentvolume/persistentvolumeclaims.
Tried defining customised RBAC inside storage-provisioner.yaml.tmp also does not work as it keep on thrown permission issue with persistentvolume(claims) and endpoints (using ClusterRole similar to defined here https://github.com/pragkent/aliyun-disk-provisioner/blob/38680a9607b0d33567be1bf0a7c57b26f0960549/deploy/rbac.yaml)
9290ab2
to
5360793
Compare
/ok-to-test |
FROM scratch | ||
COPY out/storage-provisioner storage-provisioner | ||
CMD ["/storage-provisioner"] | ||
FROM k8s.gcr.io/debian-base-amd64:v2.0.0 |
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.
Can this stay scratch
?
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 think we need to provide a build container for the copied file, right now it cheerfully builds it on the host ?
Use the normal MINIKUBE_BUILD_IN_DOCKER shenaningans, I don't see what it has do with path though...
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.
Can this stay
scratch
?
Can I resolve this conversation ? as it's clear now in the slack channel conversation that we cannot use scratch ?
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.
As long as you build static binaries (using CGO_ENABLED=0), then scratch
should be fine.
What issues are you seeing ? We know that a dynamic executable doesn't work with scratch...
But that was probably not the intention, but just a side-effect when redoing the make earlier.
I added the build container in #6257 if you want to have a look.
Is it possible to merge this PR with the previous one #5400 - with the same content ? |
This fix contains few things: * Used k8s.gcr.io/debian-base-amd64:v2.0.0 as base image to build storage-provisioner * Modify RBAC permission used to cluster-admin * Build storage-provisioner as static binary
Error: running mkcmp
|
All Times minikube: [ 112.810345 133.827582 114.781896] Average minikube: 120.473274 Averages Time Per Log
|
Looks good, do you mind addressing the merge conflict? |
/ok-to-test |
All Times Minikube (PR 6156): [ 97.411594 96.564944 94.135690] Average minikube: 97.070478 Averages Time Per Log
|
Can someone explain to me the justification for having the file system directory created use the PVC name instead of the PV name. In other words, the change at line 60 from:
to:
This means that two different applications in different namespaces can't use the same persistent volume claim name because if they do, they end up using the same directory on the filesystem, and thus they corrupt each other if directories/file names they use overlap inside the volume. This can break so many applications. It basically means you can't deploy multiple instances of the one application in different namespaces. This introduces a serious bug and is not a feature. |
The obvious solution to avoid for this would have been to use path of form |
Ah good point, I hadn't considered this.
Sounds good to me! |
#5144
This fix contains few things: