better enforcement for CR metada.name field

[acpana]

Background

For a CR that will have a status subresource, the current paradigm is to add the name of the CR as a label on the status subresource. Labels have a char limit of 64.

Current Issue

Currently we have a patch that applies to the 0th (first) version of a CRD's schema but not the rest, leaving room for mutators with long names to break status.

gatekeeper/config/crd/patches/max_name_size.yaml

Lines 1 to 6 in e47b2ba

	- op: add
	path: /spec/versions/0/schema/openAPIV3Schema/properties/metadata/properties
	value:
	name:
	type: string
	maxLength: 63

Solutions

• it would be best to have a at validation time check for "gatekeeper" related resources and that would "shift left" this check too
• however, the schema definitions need to be updated too for scenarios where the webhook is down for instance and for good API design
  • looking at some programatic way to apply the patches would be best (kpt?)
  • it may also be worth to stand up a little guide on how to contribute a CRD for gatekeeper

Things considered

• kubebuilder tags -- X needs to be applied on the metadata.name field which we cannot access in our API definitions.
• kustomize "glob" style functionality -- X not something natively supported AFAICT where we can put out a spec/versions/*/...

Misc

It would be helpful to have a gatekeeper resource specific validation/ linting step (GH action/ bash script/ etc) that validates that metadata field's schema includes

          metadata:
            properties:
              name:
                maxLength: 63
                type: string
            type: object

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[ritazh]

@acpana has this issue been fully addressed? if not, feel free to reopen.