[wip]OTA-1010: pull GetImplicitlyEnabledCapabilities from the cvo repo

[hongkailiu]

TODOs

• After OTA-1010: extract manifests with new capabilities oc#1958 and OTA-1010: Add a new version of GetImplicitlyEnabledCapabilities cluster-version-operator#1133 get merged, list in the PR description the 2 Places that are going to use the pulled function.

[openshift-ci-robot]

@hongkailiu: This pull request references OTA-1010 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.19.0" version, but no target version was set.

Details

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

[hongkailiu]

/cc @wking @petr-muller

[petr-muller]

Code is just a lift from CVO so maybe that's enough, but it actually looks quite legacy and I would be in favor of some significant refactors if this was new code. And because we're including this in a library, I believe it should meet the bar for new code.

The capabilities are basically treated as sets but we do not use apimachinery Set type and include a lot of code that would not be needed if we used it.

[petr-muller]

TBH the signature and the godoc does not help too much in understanding what is the purpose of the method and what (high-level, semantic) operation ti performs. You give it some capabilities, and it filters some out. It is supposed to return implicitly enabled capabilities, but at the same time, it filters the content of clusterCapabilities.ImplicitlyEnabledCapabilities out? That's confusing. Also, if I am a caller, how is enabledCapabilities different from clusterCapabilities.EnabledCapabilities?

Also, they are all capabilities, so calling the variables as such does not help much. Could we call them enabled and input or something that carries more semantics?

[petr-muller]

Also I think the commit and the PR needs descriptions to explain why the code is pulled from CVO and where do we intend to use it.

[hongkailiu]

I was thinking about "set" too but did not go.
Let me refactor with it now.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

• pkg/manifest/OWNERS

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

[openshift-ci-robot]

@hongkailiu: This pull request references OTA-1010 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.19.0" version, but no target version was set.

Details

In response to this:

TODO

• After OTA-1010: extract manifests with new capabilities oc#1958 and OTA-1010: Add a new version of GetImplicitlyEnabledCapabilities cluster-version-operator#1133 get merged, list in the PR description the 2 Places that are going to use the pulled function.

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]

@hongkailiu: This pull request references OTA-1010 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.19.0" version, but no target version was set.

Details

In response to this:

TODOs

• After OTA-1010: extract manifests with new capabilities oc#1958 and OTA-1010: Add a new version of GetImplicitlyEnabledCapabilities cluster-version-operator#1133 get merged, list in the PR description the 2 Places that are going to use the pulled function.

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]

@hongkailiu: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.

[openshift-bot]

Issues go stale after 90d of inactivity.

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

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

/lifecycle stale

[hongkailiu]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

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

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

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

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

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

/lifecycle rotten
/remove-lifecycle stale

[hongkailiu]

/remove-lifecycle rotten

[petr-muller]

/uncc

Cleaning up my dashboards; if I unassign from a PR where my input would still be helpful, feel free to cc/assign me back

[openshift-bot]

Issues go stale after 90d of inactivity.

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

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

/lifecycle stale

[openshift-merge-robot]

PR needs rebase.

Details

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.