The remaining bundle validation suggestions (which result in CVP warnings) are

• brokers.submariner.io does not have status spec. Note that all objects that represent a physical resource whose state may vary from the user's desired intent SHOULD have a spec and a status. More info: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
• servicediscoveries.submariner.io does not have status spec. Note that all objects that represent a physical resource whose state may vary from the user's desired intent SHOULD have a spec and a status. More info: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
• submariners.submariner.io does not have status spec. Note that all objects that represent a physical resource whose state may vary from the user's desired intent SHOULD have a spec and a status. More info: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status

It’s not clear to me why the ServiceDiscovery and Submariner CRDs show up as not having a status spec. As I understand it, the scorecard tests start the operator, and create CRs using the samples included in the bundles; these are currently nonsensical, but in my tests they do result in objects with statuses.

The Broker CRD doesn’t have a status subresource, so it’s normal that this fails. Fixing this would require changing the upstream controller to manage a status.