Add k8s name related formats #384

jpbetz · 2023-04-12T16:38:03Z

This adds the three most heavily used name formats in k8s:

"k8s-dns1123subdmain"
"k8s-dns1123label"
"k8s-dns1035label"

The k8s- prefix is added because these formats:

Are implemented in k8s in ways that do not exactly match the RFCs (RFC 952/1123 allows uppercase characters, but IsDNS1123Subdomain does not kubernetes#71140,
Incorrect max length check on metadata.name kubernetes#79351)
We intend to use these formats to communicate the existing Kubernetes validation rules via OpenAPI, so we want to keep them as-is.

Benefits:

Easier for CRDs to use the same name format already used in k8s.
Useful for Declarative Validation

xref: https://json-schema.org/draft/2020-12/json-schema-validation#name-custom-format-attributes, https://spec.openapis.org/registry/format/

liggitt · 2023-04-12T16:48:31Z

are non-standard format strings supposed to be namespaced or not?

what are the implications for CRDs created using these format strings prior to this, allowing in data that ignores those format requirements, then auto-tightening validation when upgrading to a control plane with this support added?

jpbetz · 2023-04-12T20:33:25Z

are non-standard format strings supposed to be namespaced or not?

I have not found any mention of namespacing in the specs. xref https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-01#name-custom-format-attributes

I am open to naming suggestions for these formats though. I had briefly considered something like "kubernetes-name" but couldn't think of anything that aided rather than harmed clarity on what the format actually is.

what are the implications for CRDs created using these format strings prior to this, allowing in data that ignores those format requirements, then auto-tightening validation when upgrading to a control plane with this support added?

Yes, exactly.

Today, supported formats is used strip out unsupported
formats when used in older version of the kube-apiserver. We could extend this to have
two lists: supported and storage. All new formats will be added to storage for
at least one minor release of Kubernetes before the format is added to supported so
that any usages of the new formats written to CRDs downgrade safely.

jpbetz · 2023-04-26T16:21:38Z

/assign @apelisse

Would you be willing to review?

apelisse

looks good thanks

pkg/validation/strfmt/default.go

apelisse · 2023-04-26T17:55:28Z

Thanks, looks better to me :-)

liggitt · 2023-04-27T19:06:59Z

pkg/validation/strfmt/default.go

@@ -124,6 +124,48 @@ func IsEmail(str string) bool {
 	return e == nil && addr.Address != ""
 }

+const dns1123LabelFmt string = "[a-z0-9]([-a-z0-9]*[a-z0-9])?"


if we're copying/pasting from apimachinery validation, are we inheriting these issues:

kubernetes/kubernetes#71140

This requires things to be lowercase, which is more strict than the RFC

kubernetes/kubernetes#79351 (comment)

This tolerates individual labels exceeding 63 chars, which is not as strict as the RFC

Should we fix those issues before adopting those formats here?

We intend to publish OpenAPI the in-tree types using these formats. So I think we're stuck inheriting the it all.

That said, we shouldn't using the RFC identifiers for formats that are not exactly compliant with the RFC. I'll propose some alternative names.

liggitt · 2023-04-27T19:07:41Z

pkg/validation/strfmt/default.go

+	dns1123subdomain := DNS1123Subdomain("")
+	Default.Add("dns1123subdomain", &dns1123subdomain, IsDNS1123Subdomain)
+
+	dns1123label := DNS1123Label("")
+	Default.Add("dns1123label", &dns1123label, IsDNS1123Label)
+
+	dns1035label := DNS1035Label("")
+	Default.Add("dns1035label", &dns1035label, IsDNS1035Label)


if these get added to the default set of recognized formats here, how do we roll them out in a controlled way in kubernetes?

This was held until CRD Ratcheting was promoted to beta in 1.30, we'll leverage that capability.

I'll update this code so we can manage the newly added formats separate from the pre-existing ones.

liggitt · 2023-04-27T19:20:55Z

what are the implications for CRDs created using these format strings prior to this, allowing in data that ignores those format requirements, then auto-tightening validation when upgrading to a control plane with this support added?

Yes, exactly.

Today, supported formats is used strip out unsupported formats when used in older version of the kube-apiserver. We could extend this to have two lists: supported and storage. All new formats will be added to storage for at least one minor release of Kubernetes before the format is added to supported so that any usages of the new formats written to CRDs downgrade safely.

I'm not sure I understand how that makes existing persisted CR data safe. However long we take to roll out support for the format, at some point, would we start treating existing persisted data that didn't match the specified format as invalid?

jpbetz · 2023-05-04T21:51:29Z

I'm not sure I understand how that makes existing persisted CR data safe. However long we take to roll out support for the format, at some point, would we start treating existing persisted data that didn't match the specified format as invalid?

We could solve this together with the more general problem of CRD validation ratcheting. I.e. the case where a CRD author adds a format to a CRD, and there already persisted CR data which then immediately becomes invalid. The case we are discussing is similar except that instead of the CRD author adding a format, the CRD author already had a non-validating format in the CRD and then Kubernetes changed the format to be validating.

Ratcheting rule would be: if any CR data fails validation but is unchanged from the persisted value, we ignore the validation failure and allow the update.

EDIT: This is also what we need for rollback. Note that because any format is allowed on any CRD, this would allow for rollback to arbitrary old versions.

liggitt · 2023-05-09T18:16:21Z

We could solve this together with the more general problem of CRD validation ratcheting.

I agree a solution to that would resolve the issue with this. Shouldn't we get that solution in place before adding this? This would be the first example I can think of where we made a change that would reinterpret existing persisted CRDs in ways that would invalidate existing data

jpbetz · 2023-05-09T19:04:18Z

We could solve this together with the more general problem of CRD validation ratcheting.

I agree a solution to that would resolve the issue with this. Shouldn't we get that solution in place before adding this? This would be the first example I can think of where we made a change that would reinterpret existing persisted CRDs in ways that would invalidate existing data

SGTM. I'll poke around and see who might be able to implement.

jpbetz · 2023-07-21T01:22:47Z

/close
When we circle back on this we'll either reopen or create a new PR.

k8s-ci-robot · 2023-07-21T01:22:52Z

@jpbetz: Closed this PR.

In response to this:

/close
When we circle back on this we'll either reopen or create a new PR.

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.

alexzielenski · 2023-08-18T23:18:30Z

We could solve this together with the more general problem of CRD validation ratcheting.
I agree a solution to that would resolve the issue with this. Shouldn't we get that solution in place before adding this?

Just updating progress on this front was made with CRD Ratcheting Alpha added in 1.28: https://kep.k8s.io/4008

Will need to wait for it to mature before using it for name formats, but in the interim we can use inline OpenAPI schemas to describe the regex/cel expressions used for most formats.

jpbetz · 2024-06-28T17:38:20Z

/reopen

CRD Ratcheting was promoted to beta in 1.30, freeing us up to resume progress on this.

k8s-ci-robot · 2024-06-28T17:38:26Z

@jpbetz: Reopened this PR.

In response to this:

/reopen

CRD Ratcheting was promoted to beta in 1.30, freeing us up to resume progress on this.

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-sigs/prow repository.

k8s-ci-robot · 2024-06-28T17:38:32Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jpbetz
Once this PR has been reviewed and has the lgtm label, please assign sttts for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

pkg/validation/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Organize k8s names formats into their own registry for ratcheted rollout, prefix with k8s-

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Apr 12, 2023

k8s-ci-robot requested review from apelisse and liggitt April 12, 2023 16:38

k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Apr 12, 2023

k8s-ci-robot assigned apelisse Apr 26, 2023

apelisse reviewed Apr 26, 2023

View reviewed changes

pkg/validation/strfmt/default.go Outdated Show resolved Hide resolved

liggitt reviewed Apr 27, 2023

View reviewed changes

k8s-ci-robot closed this Jul 21, 2023

k8s-ci-robot reopened this Jun 28, 2024

Add k8s name formats

efcb7bf

Organize k8s names formats into their own registry for ratcheted rollout, prefix with k8s-

jpbetz force-pushed the k8s-formats branch from 73727bd to efcb7bf Compare June 28, 2024 18:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add k8s name related formats #384

Add k8s name related formats #384

jpbetz commented Apr 12, 2023 •

edited

Loading

liggitt commented Apr 12, 2023

jpbetz commented Apr 12, 2023 •

edited

Loading

jpbetz commented Apr 26, 2023

apelisse left a comment

apelisse commented Apr 26, 2023

liggitt Apr 27, 2023

jpbetz Jun 28, 2024

liggitt Apr 27, 2023

jpbetz Jun 28, 2024

jpbetz Jun 28, 2024

liggitt commented Apr 27, 2023

jpbetz commented May 4, 2023 •

edited

Loading

liggitt commented May 9, 2023

jpbetz commented May 9, 2023

jpbetz commented Jul 21, 2023

k8s-ci-robot commented Jul 21, 2023

alexzielenski commented Aug 18, 2023

jpbetz commented Jun 28, 2024

k8s-ci-robot commented Jun 28, 2024

k8s-ci-robot commented Jun 28, 2024

Add k8s name related formats #384

Are you sure you want to change the base?

Add k8s name related formats #384

Conversation

jpbetz commented Apr 12, 2023 • edited Loading

liggitt commented Apr 12, 2023

jpbetz commented Apr 12, 2023 • edited Loading

jpbetz commented Apr 26, 2023

apelisse left a comment

Choose a reason for hiding this comment

apelisse commented Apr 26, 2023

liggitt Apr 27, 2023

Choose a reason for hiding this comment

jpbetz Jun 28, 2024

Choose a reason for hiding this comment

liggitt Apr 27, 2023

Choose a reason for hiding this comment

jpbetz Jun 28, 2024

Choose a reason for hiding this comment

jpbetz Jun 28, 2024

Choose a reason for hiding this comment

liggitt commented Apr 27, 2023

jpbetz commented May 4, 2023 • edited Loading

liggitt commented May 9, 2023

jpbetz commented May 9, 2023

jpbetz commented Jul 21, 2023

k8s-ci-robot commented Jul 21, 2023

alexzielenski commented Aug 18, 2023

jpbetz commented Jun 28, 2024

k8s-ci-robot commented Jun 28, 2024

k8s-ci-robot commented Jun 28, 2024

jpbetz commented Apr 12, 2023 •

edited

Loading

jpbetz commented Apr 12, 2023 •

edited

Loading

jpbetz commented May 4, 2023 •

edited

Loading