Skip to content
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

Merged
merged 6 commits into from Apr 8, 2020

Conversation

dmage
Copy link
Member

@dmage dmage commented Mar 31, 2020

No description provided.

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 31, 2020
@dmage
Copy link
Member Author

dmage commented Apr 1, 2020

NodeControllerDegraded: The master nodes not ready: node \"ip-10-0-133-125.us-west-2.compute.internal\" not ready since 2020-03-31 17:31:49 +0000 UTC because NodeStatusUnknown (Kubelet stopped posting node status.)\nEtcdMembersDegraded: ip-10-0-133-125.us-west-2.compute.internal members are unhealthy,  members are unknown

/retest

@dmage
Copy link
Member Author

dmage commented Apr 1, 2020

/test e2e-aws-operator

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 2, 2020
@dmage dmage changed the title WIP Add always-on controller for image-registry-certificates Apr 2, 2020
@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 2, 2020
@dmage dmage changed the title Add always-on controller for image-registry-certificates Bug 1807471: add always-on controller for image-registry-certificates Apr 2, 2020
@openshift-ci-robot openshift-ci-robot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Apr 2, 2020
@openshift-ci-robot
Copy link
Contributor

@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
  • bug is open, matching expected state (open)
  • bug target release (4.5.0) matches configured target release for branch (4.5.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1807471: add always-on controller for image-registry-certificates

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.

@dmage
Copy link
Member Author

dmage commented Apr 3, 2020

/retest

@dmage
Copy link
Member Author

dmage commented Apr 3, 2020

/retest

@dmage
Copy link
Member Author

dmage commented Apr 7, 2020

/assign @adambkaplan @ricardomaraschini

Copy link
Contributor

@ricardomaraschini ricardomaraschini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good.

Comment on lines +481 to +482
kubeInformerFactory.Core().V1().ConfigMaps(),
kubeInformerFactory.Core().V1().Services(),
Copy link
Contributor

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?

Copy link
Member Author

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.

https://github.com/kubernetes/kubernetes/blob/3758426884e3c82cbd99c72e8015f4396f21fde2/cmd/kube-controller-manager/app/apps.go#L40

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)
Copy link
Contributor

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() ?

Copy link
Member Author

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
Copy link
Contributor

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()?

Copy link
Member Author

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)
}

Copy link
Contributor

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?

Suggested change
if len(pods.Items) == 0 {
t.Fatalf("no node-ca pods found")
}

@dmage
Copy link
Member Author

dmage commented Apr 8, 2020

@ricardomaraschini ptal again

Copy link
Contributor

@ricardomaraschini ricardomaraschini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Apr 8, 2020
@openshift-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 062f6f9 into openshift:master Apr 8, 2020
@openshift-ci-robot
Copy link
Contributor

@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:

Bug 1807471: add always-on controller for image-registry-certificates

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.

@adambkaplan
Copy link
Contributor

/cherry-pick release-4.4

@openshift-cherrypick-robot

@adambkaplan: #507 failed to apply on top of branch "release-4.4":

Applying: Add always-on controller for image-registry-certificates
Using index info to reconstruct a base tree...
A	pkg/defaults/defaults.go
M	pkg/operator/controller.go
A	pkg/operator/nodecadaemon.go
M	pkg/resource/caconfig.go
M	pkg/resource/generator.go
A	test/e2e/nodecadaemon_test.go
M	test/e2e/recreate_deployment_test.go
M	test/framework/daemonset.go
M	test/framework/imageregistry.go
Falling back to patching base and 3-way merge...
Auto-merging test/framework/imageregistry.go
CONFLICT (content): Merge conflict in test/framework/imageregistry.go
Auto-merging test/framework/daemonset.go
Auto-merging test/e2e/recreate_deployment_test.go
CONFLICT (content): Merge conflict in test/e2e/recreate_deployment_test.go
CONFLICT (modify/delete): test/e2e/nodecadaemon_test.go deleted in HEAD and modified in Add always-on controller for image-registry-certificates. Version Add always-on controller for image-registry-certificates of test/e2e/nodecadaemon_test.go left in tree.
Auto-merging pkg/resource/generator.go
CONFLICT (content): Merge conflict in pkg/resource/generator.go
Auto-merging pkg/resource/caconfig.go
CONFLICT (content): Merge conflict in pkg/resource/caconfig.go
CONFLICT (modify/delete): pkg/operator/nodecadaemon.go deleted in HEAD and modified in Add always-on controller for image-registry-certificates. Version Add always-on controller for image-registry-certificates of pkg/operator/nodecadaemon.go left in tree.
Auto-merging pkg/operator/controller.go
CONFLICT (content): Merge conflict in pkg/operator/controller.go
Auto-merging defaults/defaults.go
CONFLICT (content): Merge conflict in defaults/defaults.go
error: Failed to merge in the changes.
Patch failed at 0002 Add always-on controller for image-registry-certificates

In response to this:

/cherry-pick release-4.4

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants