OTA-1029: Add a CVO Log Level API #1492
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@Davoska: This pull request references OTA-1029 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.15.0" version, but no target version was set. 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. |
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
/test all |
DavidHurta
force-pushed
the
cvo-logging
branch
from
923db57 to
9ad307f
Compare
|
/test all |
|
/cc |
DavidHurta
force-pushed
the
cvo-logging
branch
5 times, most recently
from
1056f05 to
8380ff6
Compare
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
PTAL, reviewers @LalatenduMohanty @wking @petr-muller |
|
PTAL, API approver @deads2k |
DavidHurta
force-pushed
the
cvo-logging
branch
from
8380ff6 to
3e5a661
Compare
DavidHurta
force-pushed
the
cvo-logging
branch
from
3e5a661 to
a99c2f5
Compare
JoelSpeed
left a comment
JoelSpeed
left a comment
There was a problem hiding this comment.
Apart from 2 small bits, all looks good to me
| configuration API will be introduced in the hosted cluster that would have to be | ||
| otherwise protected by a validating admission policy. | ||
|
|
||
| The configuration file may be a manifest file of a `ClusterVersionOperator` |
There was a problem hiding this comment.
Why may? May implies you haven't decided, but, I thought we had concluded that this was a good approach since it meant we already knew how to decode the object and all of the available options? I guess the one issue is if the hosted version needs a new configuration that the standalone version does not
There was a problem hiding this comment.
It's a GREAT option, and it will be implemented in such a way with the probability of 99%. My thinking was to not write in stone the definitive implementation details of such a matter.
However, now that I think about it, there is no need to leave the space open, as the option was openly discussed and was agreed upon in this enhancement. There is no need. I have updated the wording. In case we discover a greatly better alternative while developing, we can always circle back.
I guess the one issue is if the hosted version needs a new configuration that the standalone version does not
My thinking was we could then create a new API, HostedClusterVersionOperator. Its CRD would not be applied to any cluster. The hosted CVO could then load a manifest file of this kind. The CVO could then differentiate the configuration files based on the GroupVersionKind and would act accordingly. Something along these lines. A new API to communicate between components while not being exposed to users. Teaching the CVO a new configuration file format is the idea.
|
|
||
| // ClusterVersionOperatorStatus defines the observed status of the Cluster Version Operator. | ||
| type ClusterVersionOperatorStatus struct { | ||
| // observedGeneration is the last generation change you've dealt with |
There was a problem hiding this comment.
We will want to expand on this to be specific about the use case, but we can do that in the API review
There was a problem hiding this comment.
You mean the description of the observedGeneration field? Yes, it could be more descriptive about its use. Noted, thanks, I will follow up on that in the API review.
DavidHurta
force-pushed
the
cvo-logging
branch
from
9b4797e to
0c33618
Compare
|
I have squashed the commits, as there are no longer any open requests for changes (In case you want to review the last few commits, the history is present at this link). I would like to ask reviewers to explicitly state their approval of the changes or express any remaining questions or suggestions for changes. Thank you! |
|
/lgtm |
|
/lgtm Approval now down to @wking |
DavidHurta
force-pushed
the
cvo-logging
branch
from
0c33618 to
d23d516
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: petr-muller, PratikMahajan 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
bot
added
the
approved
|
@DavidHurta: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
11 participants
This enhancement describes the API changes needed to provide a simple way of dynamically changing the verbosity level of Cluster Version Operator's logs.
This pull request references https://issues.redhat.com/browse/OTA-1029