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 1905119: dynamically update controller asset for custom CA bundle #111
Bug 1905119: dynamically update controller asset for custom CA bundle #111
Conversation
@staebler: This pull request references Bugzilla bug 1905119, which is valid. 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. |
2737574
to
445a6de
Compare
@staebler, I can see that the driver installation failed with:
|
The determination about whether a custom CA bundle is being used is assessed when the operator starts. This can lead to incorrect behavior if the kube-cloud-config ConfigMap has not yet been created in the openshit-config-managed namespace when the operator starts. Instead of only looking for the ConfigMap at start-up, these changes will have the operator looking for the ConfigMap on every reconcile and adjusting the controller deployment accordingly.
445a6de
to
ede9ba3
Compare
|
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.
Just a question, the rest LGTM
return func(_ *opv1.OperatorSpec, deployment *appsv1.Deployment) error { | ||
switch used, err := isCustomCABundleUsed(cloudConfigLister); { | ||
case err != nil: | ||
return fmt.Errorf("could not determine if a custom CA bundle is in use: %w", 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.
Just to confirm: returning an error here will degrade the operator. Is that what we want?
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.
Yes, in my opinion that is what we want. But if you think otherwise, it won't hurt my feelings. Since we are using a lister, an error here is either (1) that the informer has been closed or (2) that there are RBAC restrictions preventing access to the ConfigMap. Both of those seem to me to warrant the operator being marked as degraded.
LGTM. @jsafrane? |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane, staebler 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 |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
@staebler: All pull requests linked via external trackers have merged: Bugzilla bug 1905119 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. |
The determination about whether a custom CA bundle is being used is assessed when the operator starts. This can lead to incorrect behavior if the kube-cloud-config ConfigMap has not yet been created in the openshit-config-managed namespace when the operator starts. Instead of only looking for the ConfigMap at start-up, these changes will have the operator looking for the ConfigMap on every reconcile and adjusting the controller deployment accordingly.