metadata.name validation

[jpbetz]

What do you want to happen?

@thockin had mentioned to me earlier that using CEL is problematic because of cost limits on name field:

// +kubebuilder:validation:XValidation:rule="!format.dns1123Label().validate(self.metadata.name).hasValue()",message="must be a valid DNS label"

Which let me to wonder a few things:

1. Why not just set format: k8s-short-name in the CRD declaration via Kubebuilder?
   • Reason 1.1: I don't know how to put JSON Schema validation on CRDs using +kubebuilder tags (it's possible in YAML, see below)
2. Why not just put a maxLength: 63 on metadata.name and then use the CEL format.dns1123Label() validation?
   • Reason 2.1: Same as reason 1.1
3. Why isn't CEL smart enough to know that the name field has a bounded length?
   • Reason 3.1: Because we don't embed a maxLength limit into the CRD for CEL to see today.. but we could. (Fixing this with Fix CEL cost estimates for CRD metadata.name and metadata.generateName kubernetes/kubernetes#139573)

Is anyone aware of solutions that work well today? Is there appetite for PRs to add kubebuilder support for JSON Schema metadata.name validation in Kubebuilder or is CEL the answer? If there is appetite, any recommendations for the +kubebuilder tag representation?

CRD support for metdata.name (and generateName) validation:

CRD schemas allow the name and generateName field to be validated directly using JSON Schema:

For example:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ...
spec:
  group: ...
  versions:
    - name: v1
      # ...
      schema:
        openAPIV3Schema:
          type: object
          properties:
            metadata:
              type: object
              properties:
                name:
                  type: string
                  pattern: "^required-prefix.*"  # metadata.name validation
                  maxLength: 40                     # metadata.name validation

[jpbetz]

cc @JoelSpeed @lalitc375

[JoelSpeed]

Is anyone aware of solutions that work well today?

The only example I've seen had is similar to this where we need a specific name (we want a singleton). This doesn't cause cost overflow but I know it's not ideal when you look at the aggregate cost estimation.

Why not just set format: k8s-short-name in the CRD declaration via Kubebuilder?

Because k8s-short-name isn't how CRDs validate metadata.name? k8s-long-name (ref), sure, go for it.

The only issue is that folks today need to think about backwards compatibility. Their compatibility matrix might mean they are generating CRDs that they expect users of the project to apply several versions backwards. IIRC k8s-long-name is 1.36 onwards so might be too new?

Why not just put a maxLength: 63 on metadata.name and then use the CEL format.dns1123Label() validation?

Also valid if we are using dns1123Subdomain and 253 chars, has the same, but not quite as much of an issue as the previous given compatibility and skew

If there is appetite, any recommendations for the +kubebuilder tag representation?

Thinking this should be opt-in rather than applied by default? api

[thockin]

Because k8s-short-name isn't how CRDs validate metadata.name? k8s-long-name (ref), sure, go for it.

Why is that fixed? IMO, choosing long-name as the default was a mistake and we should encourage people to use short-name when they can. But that's not my point - I was trying to validate it differently than the default and I couldn't make it work.

[jpbetz]

Why not just set format: k8s-short-name in the CRD declaration via Kubebuilder?

Because k8s-short-name isn't how CRDs validate metadata.name? k8s-long-name (ref), sure, go for it.

Tightening name validation to k8s-short-name (or any format or pattern) is allowed by CRDs. The only hard requirement that CRDs impose is that all names must be a valid k8s-long-name, so any other validation is in addition to that.

If there is appetite, any recommendations for the +kubebuilder tag representation?

Thinking this should be opt-in rather than applied by default? api

Yes, I'm imagining a way for a CRD author to opt-in. Basically, I'm imagining giving them access to validations that can be expressed today for CRDs around metadata that I don't know how to express with kubebuilder.

In DV for example, this would be represented as:

// +k8s:subfield(metadata)=+k8s:subfield(name)=+k8s:format=k8s-short-name
metav1.ObjectMeta

[sbueringer]

In DV for example, this would be represented as:

// +k8s:subfield(metadata)=+k8s:subfield(name)=+k8s:format=k8s-short-name
metav1.ObjectMeta

I think the plan was to implement support for DV tags anyway, so this would then just work