add .status.relatedObjects to clusterversion to get CVO references

[deads2k]

This will allow oc adm inspect to gather pertinent data. The CVO will need to grow a control loop that reconciles this new field. My preference will be server-side-apply, perhaps even the super naive "apply this manifest" approach.

/assign @wking

[openshift-ci]

Hello @deads2k! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k

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 [deads2k]

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

[JoelSpeed]

+listType=map and appropriate listMapKey missing

[deads2k]

+listType=map and appropriate listMapKey missing

Will do. Consideration for our future, will we fix the existing usages too?

[JoelSpeed]

If they're in status, I would expect we are already doing the right thing and so should be fine to fix it

I also assume these would ratchet 🤔

[deads2k]

Oh very neat. I think you can only make map keys on required fields and not all the fields are logically required. I might go with atomic (single writer of this thing anyway)

[JoelSpeed]

I think you can only make map keys on required fields and not all the fields are logically required

Yes I agree, the required ones are group, name and resource, so potential overlap on namespace?

If you don't have the listType enforcing the uniqueness, how about CEL?

[JoelSpeed]

For reference, the incantation is

+kubebuilder:validation:XValiadtion:rule="self.all(x, self.exists_one(y, x == y))",message="items in relatedObjects should be unique"

[JoelSpeed]

List should set a sensible maximum length, given intended use case

[deads2k]

List should set a sensible maximum length, given intended use case

I'm so glad I insisted on these linters :)

[deads2k]

/hold

I want to see this work all the way through the client before committing. I seem to recall that map keys are required to be required.

[wking]

We obviously want to include the openshift-cluster-version namespace for our operator, but "operand" gets a bit sticky with the CVO. Do we do just our own namespace on the thin end, and build out CVO logging as needed to help debug things where we don't capture enough to debug a resource we're failing to reconcile? Or all ~1k resources release-manifests are asking us to manage on the thick end? Or pick some middle ground like "asking for all ClusterOperators is easy, and likely covers reporting on most of the resources we care about"? Or...?

[JoelSpeed]

API LGTM if we are happy with the 100 resource limit

[openshift-ci]

@deads2k: The following tests 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/e2e-aws-serial-techpreview-1of2	8b7ce44	link	true	/test e2e-aws-serial-techpreview-1of2
ci/prow/integration	8b7ce44	link	true	/test integration
ci/prow/e2e-aws-ovn-hypershift	8b7ce44	link	true	/test e2e-aws-ovn-hypershift

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.