OTA-1531: [1/x] cvo: refactor option processing

[petr-muller]

Extract option validation to a new ValidateAndComplete() method, and run it separate from Run() through cobra PreRunE feature.

Refactor the AlwaysEnabledCapabilities processing to be consistent with how the other options are processed. The NewControllerContext is a method on Options struct, so it does not make sense to pass it some options through the struct, and some options through method parameters. I went further and separated the validation (performed with all other validation) from conversion, resulting in two smaller methods instead one larger one. The result is slightly less efficient but more readable.

The reason to do this refactor is that I need to clean up the NewControllerContext constructor. I will need to do some changes around, and removing the explicit pass of one option-originated argument (while all others are passed by being Options members) will make the resulting code less messy. The reasoning for the changes:

1. I need NewControllerContext to consume AlwaysEnabledCapabilities from the struct
2. To consume it from the struct, it must be validated beforehands
3. If it is validated beforehands, we do not need to track unknown and valid capabilities separately and validation can be simpler
4. It would be useful if Run could generally rely on running with "all options were validated" assumption

The reason for this refactor is that I need to clean up the NewControllerContext constructor and the Context structure so that they do not become messy after the changes needed for OTA-1531. Check out #1182 for the probe coarse implementation of the full thing.

[openshift-ci-robot]

@petr-muller: This pull request explicitly references no jira issue.

In response to this:

Extract option validation to a new ValidateAndComplete() method, and run it separate from Run() through cobra PreRunEa

Refactor the code to be consistent with how the other options are processed. The NewControllerContext is a method on Options struct, so it does not make sense to pass it some options through the struct, and some options through method parameters. I went further and separated the validation (performed with all other validation) from conversion, resulting in two smaller methods instead one larger one. The result is slightly less efficient but more readable.

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 openshift-eng/jira-lifecycle-plugin repository.

[petr-muller]

/hold

Should wait until branching at least

[petr-muller]

/retest-required

[petr-muller]

/skip

[petr-muller]

/hold cancel

[openshift-ci-robot]

@petr-muller: This pull request references OTA-1531 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.20.0" version, but no target version was set.

In response to this:

Extract option validation to a new ValidateAndComplete() method, and run it separate from Run() through cobra PreRunE feature.

Refactor the AlwaysEnabledCapabilities processing to be consistent with how the other options are processed. The NewControllerContext is a method on Options struct, so it does not make sense to pass it some options through the struct, and some options through method parameters. I went further and separated the validation (performed with all other validation) from conversion, resulting in two smaller methods instead one larger one. The result is slightly less efficient but more readable.

The reason to do this refactor is that I need to clean up the NewControllerContext constructor. I will need to do some changes around, and removing the explicit pass of one option-originated argument (while all others are passed by being Options members) will make the resulting code less messy. The reasoning for the changes:

1. I need NewControllerContext to consume AlwaysEnabledCapabilities from the struct
2. To consume it from the struct, it must be validated beforehands
3. If it is validated beforehands, we do not need to track unknown and valid capabilities separately and validation can be simpler
4. It would be useful if Run could generally rely on running with "all options were validated" assumption

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@petr-muller: This pull request references OTA-1531 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.20.0" version, but no target version was set.

In response to this:

Extract option validation to a new ValidateAndComplete() method, and run it separate from Run() through cobra PreRunE feature.

Refactor the AlwaysEnabledCapabilities processing to be consistent with how the other options are processed. The NewControllerContext is a method on Options struct, so it does not make sense to pass it some options through the struct, and some options through method parameters. I went further and separated the validation (performed with all other validation) from conversion, resulting in two smaller methods instead one larger one. The result is slightly less efficient but more readable.

The reason to do this refactor is that I need to clean up the NewControllerContext constructor. I will need to do some changes around, and removing the explicit pass of one option-originated argument (while all others are passed by being Options members) will make the resulting code less messy. The reasoning for the changes:

1. I need NewControllerContext to consume AlwaysEnabledCapabilities from the struct
2. To consume it from the struct, it must be validated beforehands
3. If it is validated beforehands, we do not need to track unknown and valid capabilities separately and validation can be simpler
4. It would be useful if Run could generally rely on running with "all options were validated" assumption

The reason for this refactor is that I need to clean up the NewControllerContext constructor and the Context structure so that they do not become messy after the changes needed for OTA-1531. Check out #1182 for the probe coarse implementation of the full thing.

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@petr-muller: This pull request references OTA-1531 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.20.0" version, but no target version was set.

In response to this:

Extract option validation to a new ValidateAndComplete() method, and run it separate from Run() through cobra PreRunE feature.

Refactor the AlwaysEnabledCapabilities processing to be consistent with how the other options are processed. The NewControllerContext is a method on Options struct, so it does not make sense to pass it some options through the struct, and some options through method parameters. I went further and separated the validation (performed with all other validation) from conversion, resulting in two smaller methods instead one larger one. The result is slightly less efficient but more readable.

The reason to do this refactor is that I need to clean up the NewControllerContext constructor. I will need to do some changes around, and removing the explicit pass of one option-originated argument (while all others are passed by being Options members) will make the resulting code less messy. The reasoning for the changes:

1. I need NewControllerContext to consume AlwaysEnabledCapabilities from the struct
2. To consume it from the struct, it must be validated beforehands
3. If it is validated beforehands, we do not need to track unknown and valid capabilities separately and validation can be simpler
4. It would be useful if Run could generally rely on running with "all options were validated" assumption

The reason for this refactor is that I need to clean up the NewControllerContext constructor and the Context structure so that they do not become messy after the changes needed for OTA-1531. Check out #1182 for the probe coarse implementation of the full thing.

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 openshift-eng/jira-lifecycle-plugin repository.

[petr-muller]

This is the main point of the change - all other o.Members are passed into NewControllerContext via Options, and the method relies on their earlier validation. Treating one Options member in a different way makes the interface messy.

[wking]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: petr-muller, wking

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:

• OWNERS [petr-muller,wking]

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

[openshift-ci]

@petr-muller: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/okd-scos-e2e-aws-ovn	40257c9	link	false	/test okd-scos-e2e-aws-ovn

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

[petr-muller]

/label no-qe

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: cluster-version-operator
This PR has been included in build cluster-version-operator-container-v4.20.0-202505062216.p0.gc410434.assembly.stream.el9.
All builds following this will include this PR.