OTA-1029: Add CVO Log level API

[Davoska]

This enhancement describes the API changes needed to provide a simple way of dynamically changing the Cluster Version Operator's log level.

This pull request references https://issues.redhat.com/browse/OTA-1029

[openshift-ci-robot]

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

In response to this:

This enhancement describes the API changes needed to provide a simple way of dynamically changing the Cluster Version Operator's log level.

This pull request references https://issues.redhat.com/browse/OTA-1029

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]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[Davoska]

/test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign sdodson for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• enhancements/update/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Davoska]

/test all

[petr-muller]

/cc

[Davoska]

Hello @enxebre, @csrwng, @sjenning 👋

This enhancement proposes to add a log level API change to the ClusterVersion resource.

After the enhancement is merged, the API change is merged, and the implementation is done in the CVO repository, a hosted cluster administrator could set an undesirable log level for its hosted CVO by modifying this new field in the hosted ClusterVersion. This enhancement proposes to fix this by implementing a reconciliation of a fixed value in the below-mentioned section in the HyperShift codebase after the API change is merged and before the implementation in the CVO repository is done.

Is this proposition for the HyperShift use case acceptable?

[Davoska]

PTAL, reviewers @LalatenduMohanty @wking @petr-muller

[Davoska]

PTAL, API approver @deads2k

[LalatenduMohanty]

I would prefer we use the same types as https://github.com/openshift/api/blob/36ce464529eb357673342c06be5886c5463cfc50/operator/v1/types.go#L92 I do not see any value changing the names when we are doing the exact same thing.

[Davoska]

I have made the reasoning more explicit in the new commit, see

enhancements/enhancements/update/cvo-log-level-api.md

Lines 53 to 56 in a99c2f5

	The type of the newly created `OperatorLogLevel` field of the CVO **cannot** be of the same type as above mentioned [`LogLevel`](https://github.com/openshift/api/blob/36ce464529eb357673342c06be5886c5463cfc50/operator/v1/types.go#L91-L107), which is defined in the `github.com/openshift/api/operator/v1` package.
	Importing the `github.com/openshift/api/operator/v1` package from inside the `github.com/openshift/api/config/v1` package causes import cycles.
	To ensure consistency across the operators and to not cause import cycles, this type will be redefined in the
	[api/config/v1/types_cluster_version.go](https://github.com/openshift/api/blob/master/config/v1/types_cluster_version.go) file.

I have also added an alternative to the proposed solution, see

enhancements/enhancements/update/cvo-log-level-api.md

Lines 199 to 205 in a99c2f5

	* The proposed solution doesn't strictly follow the DRY principle as the `LogLevel` type is copied over to the `github.com/openshift/api/config/v1` package to solve the import cycle. Another solution could be moving the data type `LogLevel` from its package `github.com/openshift/api/operator/v1` to a newly created package or to the `github.com/openshift/api/config/v1` package.
	* `github.com/openshift/api/operator/v1` package would include a modified definition for its type `LogLevel` so that no changes are required in other files.
	```go
	type LogLevel configv1.LogLevel
	```
	* `github.com/openshift/api/config/v1` package would include the original definition of the `LogLevel`.
	* This solution doesn't create any import cycles and doesn't duplicate any code. However, it moves a stable definition of a type corresponding to its package where it's heavily being used to another less logically corresponding package only due to an importing issue.

[openshift-ci]

@Davoska: all tests passed!

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[Davoska]

I am a little bit impartial regarding what option is better. Any feedback or opinions are welcomed 👍

[petr-muller]

I'm sorry if I come late to the party but I wonder whether we should future-proof a bit and carve out a substruct that clearly configures CVO (as opposed to "configures cluster"), to have a nested place for future CVO knobs?

Something like:

type ClusterVersionSpec struct {
	...
        OperatorOptions CVOOptions 
}
type CVOOptions struct {
	// operatorLogLevel controls the logging level of the cluster version operator.
	OperatorLogLevel CVOLogLevel `json:"operatorLogLevel,omitempty"`
}

[openshift-bot]

Inactive enhancement proposals go stale after 28d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle stale.
Stale proposals rot after an additional 7d of inactivity and eventually close.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale enhancement proposals rot after 7d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle rotten.
Rotten proposals close after an additional 7d of inactivity.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[petr-muller]

/remove-lifecycle rotten

[dhellmann]

This feels like the sort of thing other cluster operators might benefit from, too. Do they already have their own implementation for managing the log level?

[dhellmann]

#1555 is changing the enhancement template in a way that will cause the header check in the linter job to fail for existing PRs. If this PR is merged within the development period for 4.16 you may override the linter if the only failures are caused by issues with the headers (please make sure the markdown formatting is correct). If this PR is not merged before 4.16 development closes, please update the enhancement to conform to the new template.

[openshift-bot]

Inactive enhancement proposals go stale after 28d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle stale.
Stale proposals rot after an additional 7d of inactivity and eventually close.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale enhancement proposals rot after 7d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Mark the proposal as fresh by commenting /remove-lifecycle rotten.
Rotten proposals close after an additional 7d of inactivity.
Exclude this proposal from closing by commenting /lifecycle frozen.

If this proposal is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten enhancement proposals close after 7d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Reopen the proposal by commenting /reopen.
Mark the proposal as fresh by commenting /remove-lifecycle rotten.
Exclude this proposal from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closed this PR.

In response to this:

Rotten enhancement proposals close after 7d of inactivity.

See https://github.com/openshift/enhancements#life-cycle for details.

Reopen the proposal by commenting /reopen.
Mark the proposal as fresh by commenting /remove-lifecycle rotten.
Exclude this proposal from closing again by commenting /lifecycle frozen.

/close

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.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, OTA-1029, has status "Code Review". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, OTA-1029, has status "Code Review". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, OTA-1029, has status "Code Review". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, OTA-1029, has status "Code Review". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, OTA-1029, has status "Code Review". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.

[dhellmann]

(automated message) This pull request is closed with lifecycle/rotten. The associated Jira ticket, OTA-1029, has status "Code Review". Should the PR be reopened, updated, and merged? If not, removing the lifecycle/rotten label will tell this bot to ignore it in the future.