add featuregate status

[deads2k]

For openshift/enhancements#1373

Part 3 of a multi-step plan to make individual featuregates observable via the API. This was previously avoided because when featuregates get promoted from TechPreview to Default, during an upgrade, an old operator may try to enable a TechPreview variant of a feature.

This can be addressed by keying the featuregates by version. Let's see how ugly that will be in practice now that we have a decent build-out of library-go.

Unit tests are still owed. Proof is still owed. cluster-config-operator controller is still owed.

/hold

This is proving the concept, not to be merged until it shows as working end-to-end.

Other steps include

1. demonstrate usage in a non-bootstrap operator. probably something like openshift-apiserver or authentication
2. enhancements write up describing how it works end to end.
3. need to render out a version of FeatureGates that includes status for the featuregates to use during bootstrapping and plumb that through the installer.

/assign @JoelSpeed

[JoelSpeed]

No feedback on initial pass, will do another review once we have a demo end to end

[deads2k]

now with unit tests.

launch openshift/cluster-config-operator#288,openshift/cluster-kube-apiserver-operator#1459 gcp started a cluster.

That's enough to get started. library-go and this need to merge in quick succession. The bump in kas-o can happen a bit later. The installer change can come latest. At worst, I can make that one vendor openshift/api if I get no response.

[JoelSpeed]

One nit otherwise I think this is fine, tests seem to be comprehensive.

One quick note, a point of friction that will likely come up is that people will have to agree the API change and then make sure CCO is revendored with the appropriate change. I expect the map in configv1 has sufficient consumers that it would be a pain to move the source of truth here, but, we should ensure the enhancement records why there is a split between the two repos so we have something to point people to

[JoelSpeed]

I tend to dislike naked err returns and insist on fmt.Errorf("<context>: %w", err) to make things easier to debug down the line, up to you if you want to fix those throughout this controller or not, I expect you'll be the first one debugging errors

[deads2k]

/hold cancel

this is the next step in line. Make the API available to consumers

[JoelSpeed]

/lgtm

Discussed in slack, future todo to move to configv1.FeatureGateName rather than lots of string casting, but not an issue now as this should be internally scoped to this controller

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, JoelSpeed

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [deads2k]

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

[deads2k]

https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_cluster-config-operator/288/pull-ci-openshift-cluster-config-operator-master-e2e-aws-ovn/1650576003732344832 shows working-ness

[deads2k]

adding valid bug because this is needed to unstick the cloud contorller manager bug

[deads2k]

upgrade showing green as well https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_cluster-config-operator/288/pull-ci-openshift-cluster-config-operator-master-e2e-upgrade/1650576003778482176

github is being slow. I'm merging to fix the next two problems.