WIP - Bug 1808118: Implemented operator log level controller #593
Conversation
openshift-ci-robot
added
do-not-merge/work-in-progress
|
@ricardomaraschini: This pull request references Bugzilla bug 1808118, 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
DetailsIn 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: ricardomaraschini The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
| OperatorSpec: operatorapi.OperatorSpec{ | ||
| LogLevel: operatorapi.Normal, | ||
| OperatorLogLevel: operatorapi.Normal, | ||
| }, |
There was a problem hiding this comment.
this is a somewhat awkward way to do this since you're putting operator config info into an operand config resource.
while it may work ok for now since registry is a singleton, it would be a problem if you wanted to allow multiple registry instances and in general doesn't feel quite right.
have any other operators addressed this? what pattern did the use?
There was a problem hiding this comment.
operator/v1.OperatorSpec is a generic Spec for all operators, so many other operators work the same way.
We won't want to have multiple registry instances because the registry itself is a singleton: it uses k8s api as to storage metadata (ImageStreams).
There was a problem hiding this comment.
i know multiple registry instances will almost certainly never be a thing, but it still seems slightly odd for the operand config resource to control the operator, so i'd like to know we have other operators that work that way.
after a bit of poking around it seems like we do, so i guess this is fine, if slightly unfortunate imho
There was a problem hiding this comment.
@bparees I agree, that's because this config is started as a config for the operand, and other similar resources are started as configs for the operators. To make this config similar to other configs, it was transformed into a config for both: the operator (mostly status) and the operand (mostly spec). Both are singletons, so it works. Maybe eventually we'll split it and have two separate resources.
|
/retest |
|
/test e2e-aws |
|
/test unit |
Updating openshift/api and added package github.com/openshift/library-go/pkg/operator/loglevel
LogLevel controller keeps track of Operator and Operand log levels.
|
/retest |
|
@ricardomaraschini: PR needs rebase. DetailsInstructions 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. |
openshift-ci-robot
added
the
needs-rebase
|
Closed in favor of #601 |
|
@ricardomaraschini: This pull request references Bugzilla bug 1808118. The bug has been updated to no longer refer to the pull request using the external bug tracker. DetailsIn 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. |
4 participants
LogLevel controller keeps track of Operator and Operand log levels.