-
Notifications
You must be signed in to change notification settings - Fork 611
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
[manila-csi-plugin] Support for cloud-config
secret
#2532
Comments
I don't know detail of Manila about its secret mgmt if what you said apply to it I agree it's reasonable to update |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
+1 for this. When we deploy Kubernetes, we create one secret containing a It would be less of a problem if Manila didn't require the region to be specified, which should be implicit in the application credential (it is for the other components), although still irritating. |
I'm also interested in this feature. Without having looked, I doubt Manila genuinely needs Region, btw. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
@GlassOfWhiskey at first glance it looks like manila has its own specific set of secrets because csi-controller dynamically passes them to the node controller using CSI spec request. |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
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-sigs/prow repository. |
/reopen |
@gouthampacha: Reopened this issue. In response to this:
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-sigs/prow repository. |
/kind feature
What happened: All the other OpenStack-related plugins support a
cloud-config
secret that contains credentials for authentication with the keystone. Conversely, Manila CSI Plugin wants its own format for auth secrets, making it difficult to integrate it with existing Kubernetes-on-Openstack environments (e.g., the Charmed Kubernetes Distribution.What you expected to happen: it would be easier to mount the same
cloud-config
secret in all the OpenStack plugins ecosystem, instead of having a different integration path just for Manila. Is it something feasible?The text was updated successfully, but these errors were encountered: