Validate names of resources at the preview stage?

[oliverholliday]

I quite often (I know I should have learned by now) create resources with names that kube rejects - pulumi doesn't reject the name until it's tried to create the resource and errored.

Is there a way to validate names at the preview stage?

e.g.

kubernetes:core:Secret certs-DNS01 creating Retry #0; creation failed: 
Secret "certs-DNS01" is invalid: metadata.name: Invalid value: "certs-DNS01": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

[hausdorff]

I think it's sufficient to check that the name is DNS-1123 compliant. @lblackstone @metral ?

[metral]

Agreed. I myself have run into this as well. I've implemented some string trimmers and length enforcers in utility classes to get around this, but it'd be great for this to be validated during preview.

[lblackstone]

I'm unclear on which resources would need this validation enforced, and don't want to produce false-positive errors based on client-side validation. I'm going to hold off on this for now. Two possible options we discussed offline are:

1. Validate names for specific resource kinds (e.g., Pod, Service) against DNS-1123. This would need further testing/research to ensure that this requirement is not specific to the k8s plugins in use.
2. Perform a dry-run apply of the k8s resources during preview to see if they would fail during update.

[hausdorff]

Note that dry-run won't be applicable when there are computed values in the resource definition. You'll have to skip validation entirely in that case.

[oliverholliday]

Even just this level of validation would be a help for me:

By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, -, and ., but certain resources have more specific restrictions.

https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

The azure provider fails on name checks at preview time and it's a far less jarring experience.

Once a preview has passed, the PR has been approved and the CI server runs the update and fails it's a real pain point to redo the whole process - especially for something so trivial.

[lblackstone]

@oliverholliday Looking at the k8s validation code, those naming conventions don't seem to be enforced uniformly across resources. https://github.com/kubernetes/kubernetes/blob/1d441c1f93e7cc44f8a200df28a2c8a4bee3a2bb/staging/src/k8s.io/apimachinery/pkg/api/validation/generic.go#L28-L32

I realize this is a bad user experience, but I'm hesitant to add client-side validation that may not match what k8s is enforcing.

That being said, it would be easy to add for specific resources/fields if we could track down what rules are being enforced. That's probably not too hard for just the .metadata.name field on common resource kinds.

[hausdorff]

What's the reason we can't do something like (the client-go equivalent of) --dry-run?

[blampe]

Previews always perform --dry-run nowadays.