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
Bug 1936871: allow setting a custom config for the driver #29
Conversation
@Fedosin: This pull request references Bugzilla bug 1936871, which is invalid:
Comment 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/test-infra repository. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Fedosin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/bugzilla refresh |
@Fedosin: This pull request references Bugzilla bug 1936871, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (rlobillo@redhat.com), skipping review request. 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/test-infra repository. |
/assign @mandre |
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'm not very keen on changing the default config, but according to the ignore-volume-az documentation the volume node affinity effectively prevents attaching to the node if the compute zone doesn't match the volume one when Topology feature is turned on (that's the case for openshift).
@jsafrane is there a way to update the csi driver config as day2 similarly to what we're doing for the in-tree cinder provisioner? I'd prefer that if that was an option.
In-tree volume plugin seems to be controller by ConfigMap The Cinder operator should watch this ConfigMap and update Deployment/DaemonSet accordingly via DeploymentHook / DaemonSetHook, see e.g. how AWS EBS operator modifies Deployment to inject optional CA bundle into Deployment ) |
/test e2e-openstack |
This patch allows users to set custom config for the driver. To do so, they need to create a config map called "openstack-cinder-custom-config" in "openshift-cluster-csi-drivers" namespace, with a key "cloud.conf". If this config map exists, then the driver will use the custom config.
@Fedosin: This pull request references Bugzilla bug 1936871, which is valid. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (rlobillo@redhat.com), skipping review request. 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/test-infra repository. |
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'm uncomfortable with this change. As currently designed it could be improved as noted in review comments by:
- changing the configmap which we pass to the deployment rather than passing a second one
- refactoring the 2 podspec mutating methods to use common code
However, I'm more generally uncomfortable with the design of the feature.
It requires the user to pass in our default configuration in addition to any new configuration they want to add. This presents us with an incredibly messy upgrade problem if we ever need to change this.
It requires the user to pass in raw configuration at all. Can we not add an operator parameter which would set this, for eg?
If we decide to go with the user passing in config, please can we have them pass in an ini fragment which is merged with and overrides the default configuration? We should note in the documentation that they should not include any configuration directives that they don't want to override. In this way they could pass in simply:
[BlockStorage]
ignore-volume-az = true
rather than
[Global]
use-clouds = true
clouds-file = /etc/kubernetes/secret/clouds.yaml
cloud = openstack
[BlockStorage]
ignore-volume-az = true
/hold
return nil | ||
} | ||
deployment.Spec.Template.Spec.Volumes = append(deployment.Spec.Template.Spec.Volumes, corev1.Volume{ | ||
Name: "custom-config", |
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.
If we're just doing a simple replace, why mount both config maps? Why not mount the custom one in place of the default?
continue | ||
} | ||
container.Env = append(container.Env, corev1.EnvVar{ | ||
Name: "CLOUD_CONFIG", |
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.
Looks like this will define CLOUD_CONFIG twice? Looks kinda weird.
case !used: | ||
return nil | ||
} | ||
daemonset.Spec.Template.Spec.Volumes = append(daemonset.Spec.Template.Spec.Volumes, corev1.Volume{ |
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.
These 2 methods should be refactored to a use a common function which modifies, e.g. a PodSpec.
I discussed this with @mandre earlier and we both have the same concern about the upgrade issue if we force the user to fork our default configuration. We discussed the possibility of having some operator config which would write a new config itself containing The 2 options we discussed for merging a default configuration with a user-supplied additional config were:
Either of these would work for me as they both avoid the upgrade problem which is the real issue here. I personally prefer the latter as it would be cleaner, so I'm going to see if I can write that and propose it against upstream CPO on Monday. If we had that we'd just need some tweaks to this PR to add the second configfile to the command line in addition to the changes it already makes. |
kubernetes/cloud-provider-openstack#1476 would allow specifying multiple config files, which would make this much cleaner and remove the upgrade problem. |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
@Fedosin: PR needs rebase. 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. |
This patch allows users to set custom config for the driver. To do so, they need to create a config map called "openstack-cinder-custom-config" in "openshift-cluster-csi-drivers" namespace, with a key "cloud.conf".
If this config map exists, then the driver will use the custom config.