Discussion: practical name budgets for Grove-generated resources

[yankay]

Hi maintainers,

While following up on #658 and #659, I noticed that Grove has several generated-resource naming paths where user-controlled names can unexpectedly consume Kubernetes name or label budgets.

The immediate issue was a generated Secret name being copied into app.kubernetes.io/name, which is limited to 63 characters. The old -initc-sa-token-secret suffix left only 41 characters for the PodCliqueSet name when used as a label value.

Grove already has an effective pod-name budget:

• standalone PodClique: len(pcsName) + len(pclqName) <= 45
• PodClique in PCSG: len(pcsName) + len(pcsgName) + len(pclqName) <= 45

I think it would be useful to discuss practical naming guidance before deciding whether Grove should add more admission validation.

Questions:

1. Which user-controlled name components should Grove document as part of a shared generated-resource budget?
2. Should Grove publish soft planning targets, instead of only hard validation formulas?
3. Which generated resources need a complete naming-pattern inventory and boundary tests?
4. Should admission validation enforce only proven hard limits, while docs recommend softer headroom?

Areas to include:

• PodCliqueSet name
• PodCliqueScalingGroup template name
• PodClique template name
• generated PodClique, PodCliqueScalingGroup, Pod, PodGang, Service, Role, RoleBinding, ServiceAccount, Secret, ResourceClaim, and ComputeDomain names
• generated names copied into labels such as app.kubernetes.io/name

Suggested starting point for discussion:

• Keep PodCliqueSet names around 24 characters when possible.
• Keep standalone PodClique template names around 12 characters.
• Keep PCSG template names around 10-14 characters.
• Keep PodClique template names inside PCSG around 8-12 characters.
• Prefer generated Pod names to stay at or below 35 characters when possible.
• Keep Auto-MNNVL group names short because ComputeDomain / RCT naming includes the PCS name, replica index, and MNNVL group name.
• Complete a generated-resource naming inventory before adding new hard validation.

This seems related to the existing naming guide, which documents Grove's hierarchical pod/resource naming patterns but does not appear to cover this ResourceClaim pod-local name budget yet:
https://github.com/ai-dynamo/grove/blob/main/docs/user-guide/02_pod-and-resource-naming-conventions/02_naming-conventions.md

Related context:

• pod/resource naming docs: doc: Add pod-naming and environment-variables docs #355
• current pod-name budget: Pod name validation pgs #105
• ongoing pod-name changes: Add pod clique pod index to pod name for better visibility #635 and feat: add pod clique pod index to pod names #634
• Auto-MNNVL generated ComputeDomain naming: https://github.com/ai-dynamo/grove/blob/main/docs/proposals/417-auto-mnnvl/README.md
• ResourceClaim naming patterns: https://github.com/ai-dynamo/grove/blob/main/docs/proposals/390-hierarchical-resource-sharing/README.md

Similar Kubernetes precedents:

• Cronjobs with names longer than 52 characters fail to schedule jobs kubernetes/kubernetes#50850
• StatefulSet with long name can not create pods kubernetes/kubernetes#64023
• Unable to create LWS object with name above 51 characters kubernetes-sigs/lws#410

Expected outcome: agree on documentation guidance, identify any hard limits worth validating, and add boundary tests for generated-resource naming where appropriate.

[oleg-kushniriov]

Thanks for raising this - the concern is real.

One thing I'm wondering about is whether the naming constraints here are actually two different problems that might need different solutions.

For cases where a single user-controlled name is copied directly into a bounded slot - like app.kubernetes.io/name - the limit is per-field and independent of everything else. The fix in #659 looks right for that. There are probably more instances of this pattern, and each one seems like a targeted fix: one field, one limit, one check.

For compound generated names (Pods, Secrets, etc.) built from multiple user inputs concatenated with fixed suffixes, I'm less sure per-field soft targets are the right model. If what actually matters is the total - e.g. len(pcsName) + len(pcsgName) + len(pclqName) + len(suffix) <= 253 - then validating individual components independently could end up more restrictive than the real Kubernetes limit, without giving users any way to trade budget between fields. A total-budget check at admission might be more flexible, though it does require the admission webhook to simulate name generation, which is only clean if the formula is deterministic at admission time.

I'd also be cautious about soft planning targets in docs as a substitute for validation - in practice users tend not to find them until after they've already committed to a name in a production workload.

On sequencing, the suggestion to complete the naming inventory before adding new validators seems right to me, especially with patterns actively changing in #635/#634.

[renormalize]

I mirror @oleg-kushniriov's opinions on this.

We already perform a total-budget check at admission (all conventions are deterministic anyway).

I think len(pcsName) + len(pcsgName) + len(pclqName) + seperators <= 64 is main check necessary since the pod hostname can not exceed 64 characters; which #634 already incorporates.

[oleg-kushniriov]

@yankay - can you please share an example in which our current validation fails

[yankay]

@yankay - can you please share an example in which our current validation fails

HI @oleg-kushniriov

One concrete example is resourceSharing, where the generated ResourceClaim name is also copied into pod.spec.resourceClaims[].name.

apiVersion: grove.io/v1alpha1
kind: PodCliqueSet
metadata:
  name: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
spec:
  replicas: 1
  template:
    resourceClaimTemplates:
      - name: shared-gpus
        templateSpec:
          spec:
            devices:
              requests:
                - name: gpu
                  exactly:
                    deviceClassName: gpu.example.com
    cliques:
      - name: workr
        resourceSharing:
          - name: shared-gpus
            scope: AllReplicas
        spec:
          roleName: worker
          replicas: 1
          minAvailable: 1
          podSpec:
            containers:
              - name: worker
                image: busybox:latest
                command: ["sleep", "infinity"]

I tested this locally in Kind. The PCS admission passed and the PCLQ/ResourceClaim were created, but Pod creation failed with:

spec.resourceClaims[0].name: Invalid value: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-0-workr-all-shared-gpus": must be no more than 63 characters

Here is the simplified breakdown:

Case	Generated value	Gap
resourceSharing ResourceClaim	<owner-name>-all-<rct-name> / <owner-name>-<replica>-<rct-name>	This value is reused as pod.spec.resourceClaims[].name, but current validation does not check its DNS_LABEL budget (<=63).
Related fixed case: #659	<pcs-name>-initc-sa-token-secret	Same class of issue: a generated name was reused as app.kubernetes.io/name, whose label value also has a <=63 limit.
Auto-MNNVL ComputeDomain	<pcs-name>-<replica>-<mnnvl-group>	Likely same class: mnnvl-group is validated alone, but the combined generated name may still exceed fields such as app.kubernetes.io/name.