-
Notifications
You must be signed in to change notification settings - Fork 267
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
Add support for imagePullSecrets #2589
Conversation
Hi @garonsky. Thanks for your PR. I'm waiting for a kubevirt 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. |
thanks for the pr @garonsky! /ok-to-test |
/test pull-containerized-data-importer-e2e-ceph |
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.
@garonsky thanks for the PR, great start! Looks like we mostly just have to flush out the support for worker pods and.
cmd/cdi-controller/controller.go
Outdated
@@ -57,6 +58,7 @@ var ( | |||
uploadProxyServiceName string | |||
configName string | |||
pullPolicy string | |||
imagePullSecrets []corev1.LocalObjectReference |
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 variable is not assigned to. But I suggest a different approach for setting imagePullSecrets
on worker pods.
There are a bunch of places in pkg/controller
where pods are created. We should handle imagePullSecrets
similar to how podResourceRequirements
are handled by looking up the value in CDIConfig
at pod creation time.
ImagePullPolicy corev1.PullPolicy `json:"imagePullPolicy,omitempty" valid:"required"` | ||
ImagePullPolicy corev1.PullPolicy `json:"imagePullPolicy,omitempty" valid:"required"` | ||
// The imagePullSecrets to pull the container images | ||
ImagePullSecrets []corev1.LocalObjectReference `json:"imagePullSecrets,omitempty"` |
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 assume that we want regular users to know the names of secrets we expect them to create? So I suggest moving ImagePullSecrets
to CDIConfig
. So CDI will look like this:
...
kind: CDI
spec:
config:
imagePullSecrets:
- secret-name
...
And CDIConfig should have imagePullSecrets
in the status like so:
...
kind: CDIConfig
metadata:
name: config
spec:
imagePullSecrets: #set by config-controller
- secret-name
status:
imagePullSecrets:
- secret-name
...
CDIConfig has a singleton (named config) that is created by the config-controller and readable by all users. The spec
section is spec.config
from the CDI resource.
I refer you again to how PodResourceRequirements
are handled
aa3d219
to
68c8ab4
Compare
@mhenriks thank you for the great feedback! I tried to implement the suggestions, let me know if this is more of what you had in mind. |
117408e
to
9c33139
Compare
images from repositories that require secrets. The imagePullSecrets is propagated to the following components: cdi-apiserver, cdi-deployment, and cdi-uploadproxy. The definition of imagePullSecrets in cdi-operator must be done manually. Signed-off-by: Gleb Aronsky <gleb.aronsky@windriver.com>
9c33139
to
15e33dc
Compare
15e33dc
to
523fd40
Compare
@garonsky I did a quick scan and I think this looks great! I will dig a little deeper tomorrow and keep you posted. Sorry for the delayed response. Been on PTO. |
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.
Great work! Couple places that need pull secrets:
I think that's it!
pkg/controller/import-controller.go
Outdated
@@ -867,6 +868,8 @@ func createImporterPod(log logr.Logger, client client.Client, args *importerPodA | |||
return nil, err | |||
} | |||
|
|||
args.imagePullSecrets = cdiv1.CDIConfig{}.Spec.ImagePullSecrets |
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.
Should be calling GetImagePullSecrets
here, right?
523fd40
to
7dbfbb8
Compare
@mhenriks Thank you so much for the guidance! I made some changes. Let me know if I captured your suggestions with the latest changes. |
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.
@garonsky seems to work well, just one bug I found
pkg/controller/config-controller.go
Outdated
func (r *CDIConfigReconciler) reconcileImagePullSecrets(config *cdiv1.CDIConfig) error { | ||
if config.Spec.ImagePullSecrets != nil { | ||
config.Status.ImagePullSecrets = config.Spec.ImagePullSecrets | ||
} |
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.
config.Status.ImagePullSecrets
will not get unset if config.Spec.ImagePullSecrets
deleted
Signed-off-by: Gleb Aronsky <gleb.aronsky@windriver.com>
7dbfbb8
to
d3490cb
Compare
/lgtm Thanks @garonsky! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mhenriks 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 |
Fixes #2395 |
Add support for imagePullSecrets in the CDI CR to support pulling images from repositories that require secrets.
The imagePullSecrets is propagated to the following components: cdi-apiserver, cdi-deployment, and cdi-uploadproxy. The definition of imagePullSecrets in cdi-operator must be done manually.
Does this PR introduce a user-facing change?