Failed to create PV if the secret name length is greater than 63 chars

[Madhu-1]

When the secret name length is greater than 63 chars the PV creation is failing with below error

I0217 10:30:34.838278       1 controller.go:860] Started provisioner controller rook-ceph.rbd.csi.ceph.com_csi-rbdplugin-provisioner-6d765b47d5-vpp4c_e448436b-7129-4228-8bfd-ca6a7ead8a5b!
I0224 02:48:28.628887       1 controller.go:1337] provision "default/rbd-pvc1" class "rook-ceph-block1": started
I0224 02:48:28.642229       1 event.go:285] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"rbd-pvc1", UID:"b29b319d-986f-4cd1-b537-cbf0e5ba62bb", APIVersion:"v1", ResourceVersion:"1339014", FieldPath:""}): type: 'Normal' reason: 'Provisioning' External provisioner is provisioning volume for claim "default/rbd-pvc1"
I0224 02:48:28.852218       1 controller.go:1442] provision "default/rbd-pvc1" class "rook-ceph-block1": volume "pvc-b29b319d-986f-4cd1-b537-cbf0e5ba62bb" provisioned
I0224 02:48:28.852668       1 controller.go:1455] provision "default/rbd-pvc1" class "rook-ceph-block1": succeeded
E0224 02:48:28.869627       1 volume_store.go:90] Failed to save volume pvc-b29b319d-986f-4cd1-b537-cbf0e5ba62bb: error saving volume pvc-b29b319d-986f-4cd1-b537-cbf0e5ba62bb: PersistentVolume "pvc-b29b319d-986f-4cd1-b537-cbf0e5ba62bb" is invalid: spec.csi.name: Invalid value: "rook-ceph-client-cephclient-rbd-provisioner-storageconsumer-129e6746-6ba2-4dfc-9a64-18bab83a695a": must be no more than 63 characters
E0224 02:48:28.872697       1 volume_store.go:144] error saving volume pvc-b29b319d-986f-4cd1-b537-cbf0e5ba62bb: PersistentVolume "pvc-b29b319d-986f-4cd1-b537-cbf0e5ba62bb" is invalid: spec.csi.name: Invalid value: "rook-ceph-client-cephclient-rbd-provisioner-storageconsumer-129e6746-6ba2-4dfc-9a64-18bab83a695a": must be no more than 63 characters

Steps to reproduce

• Create secret with name length greater than 63 chars
• Create storageclass (specify the secret name for provisioner and node secret)
• Create PVC

If the secret creation with a name greater than 63 chars are allowed and specifying the same length name is allowed in storageclass parameters why not allow the creation of PV objects?

[Madhu-1]

cc @jsafrane @msau42 @xing-yang

[Madhu-1]

As the issue is not in the external-provisioner, I created an issue here as it's trying to create the PV. it's a generic problem with both dynamic PVC and static PV. if we want I can open an issue in the kubernetes repo also.

[humblec]

Consider this field belong to or validation goes through via metadata.name field where 63 chars limit restriction has been imposed, I doubt this qualify as a bug,

As per kubernetes CO, the secret name should be a valid DNS subdomain name ( RFC 1123) https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names , so creation of secret (>63 char) has covered with that. Having it in sc opaque Key value param list is also fine. However while spec has been saved, the validation goes through spec.csi.name which currently has a restriction of 63 char mentioned above.

[pohly]

PV.spec.csi is the CSIPersistentVolumeSource in the PersistentVolumeSource, right? But it doesn't have a name field.

Is that perhaps referring to the name field in one of the secret references? Then validation in Kubernetes has a bug because it doesn't properly construct the field path.

Does the name validation there use stricter rules than the name validation for secret objects? @Madhu-1 said "Create secret with name length greater than 63 chars", so I am assuming that this worked.

[humblec]

PV.spec.csi is the CSIPersistentVolumeSource in the PersistentVolumeSource, right? But it doesn't have a name field.

Is that perhaps referring to the name field in one of the secret references? Then validation in Kubernetes has a bug because it doesn't properly construct the field path.

afaict, the spec.csi.name field validation caught secretReference->name in its path here and validation is currently imposed with 63 char limit we have on CSI->Name field by the CSI spec. May be depend on other opinions here and conclusion, we could try to solve it by constructing the name field validation to the actual child object name validation schema.

Does the name validation there use stricter rules than the name validation for secret objects? @Madhu-1 said "Create secret with name length greater than 63 chars", so I am assuming that this worked.

It will work (ie secret creation wil work) , as mentioned in above comment (#708 (comment)) the secret object name has to be DNS subdomain name which is "253" char by the RFC.

[Madhu-1]

PV.spec.csi is the CSIPersistentVolumeSource in the PersistentVolumeSource, right? But it doesn't have a name field.

Is that perhaps referring to the name field in one of the secret references? Then validation in Kubernetes has a bug because it doesn't properly construct the field path.

yes its the secret name field

Does the name validation there use stricter rules than the name validation for secret objects? @Madhu-1 said "Create secret with name length greater than 63 chars", so I am assuming that this worked.

Yes, the creation of secrets is allowed till the limit of 253 chars but reference it is not allowed in the PV object.

@pohly we need to decide we need to increase the char limit in the validation or not. at least if not possible fail fast before provisioning the PV or creating the storage resources. it does not make sense to create all the storage resources and fail to create the PV. This can also cause the storage resource leak like #486

[jsafrane]

It seems like a bug in the validation, Secret.Name is validated by NameIsDNSSubdomain (253 characters), while ValidateDNS1123Label is used to validate the secret refs (63 characters).

In addition, the field path is constructed wrong after all ValidateDNS1123Label calls: https://github.com/kubernetes/kubernetes/blob/016b96ca3896d27b37c5b2d6e223fb3320a0fdec/pkg/apis/core/validation/validation.go#L1564-L1568

It's interesting that field.Required errors are reported correctly (controllerPublishSecretRef.name), while ValidateDNS1123Label errors use only name.

[jsafrane]

In other words, feel free to fix the secret ref validation to use ValidateSecretName() instead of ValidateDNS1123Label.
And please fix the field reporting, this is very confusing.

[humblec]

Thanks @jsafrane , indeed this is confusing and goes wrong in the validation path. I can drop the fix 👍

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.