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 1807471: add always-on controller for image-registry-certificates #507
Conversation
/retest |
/test e2e-aws-operator |
@dmage: This pull request references Bugzilla bug 1807471, 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
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. |
/retest |
/retest |
/assign @adambkaplan @ricardomaraschini |
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.
Looking good.
kubeInformerFactory.Core().V1().ConfigMaps(), | ||
kubeInformerFactory.Core().V1().Services(), |
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't we use a single parameter here of type v1.Interface
?
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 try to use the upstream approach for controllers. I think their code is cleaner and we have a lot to learn from them.
In this case v1.Interface
instead of two informers will be much more opaque dependency. I don't want to read this code few month later and think:
Do it really wants to use all corev1 types?! I don't think so, but what kind of objects does this controller really need? Meh, I need to read its code...
} | ||
|
||
func (c *ImageRegistryCertificatesController) sync() error { | ||
g := resource.NewGeneratorCAConfig(c.configMapLister, c.imageConfigLister, c.openshiftConfigLister, c.serviceLister, c.coreClient) |
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.
Could this be done when creating the object on NewImageRegistryCertificatesController()
?
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.
Generators are lightweight objects (i.e. their constructors are trivial) and in this case it should be created on stack, so it doesn't matter. Eventually I'd expect us to get rid of these generators and inline them into controllers.
te.Fatalf("unable to get the current state of daemonset/node-ca: %s", err) | ||
} | ||
|
||
policy := metav1.DeletePropagationBackground |
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.
Isn't it possible to use DeletePropagationForeground
here so we don't need to wait with WaitUntilFinalized()
?
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.
DeletePropagationForeground doesn't wait the object is finalized anyway, it's an instruction for GC. For daemonsets deleting its children can be slow. I'd prefer it to stay as a background job.
@@ -27,8 +34,6 @@ func TestNodeCAGracefulShutdown(t *testing.T) { | |||
t.Fatalf("unable to list pods: %v", err) | |||
} | |||
|
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 was looking at the error being reported by CI on this test and it seems like we could not find any pod to attach to(that would be very strange). Would you mind incorporating this slight change to make things clear?
if len(pods.Items) == 0 { | |
t.Fatalf("no node-ca pods found") | |
} |
@ricardomaraschini ptal again |
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dmage, ricardomaraschini 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 |
@dmage: All pull requests linked via external trackers have merged: openshift/cluster-image-registry-operator#507. Bugzilla bug 1807471 has been moved to the MODIFIED state. 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. |
/cherry-pick release-4.4 |
@adambkaplan: #507 failed to apply on top of branch "release-4.4":
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. |
No description provided.