Staging repository just for `constants`

[Davanum Srinivas]

Hi sig-arch / sig-api-machinery,

I would like to propose a small new staging module, k8s.io/constants, with a working implementation in PR #135896.

Well-known Kubernetes constants are scattered across apimachinery/pkg/util/validation, apimachinery/pkg/api/validate/content, apimachinery/pkg/apis/meta/v1/validation, and a dozen well_known_*.go files under api/core/v1, api/networking, api/discovery, cloud-provider/api, and kubelet/pkg/apis. 

Concretely, k8s.io/api/resource/v1 pulls in the entirety of util/validation — regex engine, error aggregation, the whole surface — for a single integer (issue #127889). External consumers pay the same tax whenever they need a well-known label key or DNS length limit.

The proposal is a zero-dependency staging module at k8s.io/constants with five subpackages.

- rfc/ — length constants for Kubernetes name-like fields (docs describe the Kubernetes grammars, not strict RFC compliance; aligned with KEP-5311 and kube-openapi#384).
- limits/ — LabelValueMaxLength, LabelKeyMaxLength, FieldManagerMaxLength.
- labels/, annotations/, taints/ — well-known keys. Identifiers drop the package-name prefix (labels.Hostname, not labels.LabelHostname).

The PR should be hopefully small, non-behavioural, and non-breaking. I'll add this to an upcoming sig-arch meeting agenda, if that works!

thanks,
Dims

--

Davanum Srinivas :: https://twitter.com/dims

[Ricardo Pchevuzinske Katz]

I am a +1 on this. As someone constantly trying to find all of the well known keys, and all of the definitions of RFCs and limits (I was just doing it yesterday) I think this will be a huge gain with minimal effort.

Thanks Dims!

--
You received this message because you are subscribed to the Google Groups "sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-architectu...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CANw6fcFAi%3D0O36iicjOTxb2cRVL4T9qikBxFmfvoNHj-v3X9BA%40mail.gmail.com.

[Benjamin Elder]

I +1 the question in the PR if this should be an actual repo instead of a staging repo, so it's easier to depend on.

I think staging only makes sense if we expect to modify these frequently in lockstep with the main repo.

Otherwise +1 to the concept to move these to a dedicated zero-dependency repo.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CAApfV%3D0ZuG4jVPSRDn0mDNMLn-pn9dogt%3DptkHJzo8DT%3DQskDg%40mail.gmail.com.

[Davanum Srinivas]

Ben,

I want to see over time how we use it. if we see for like 3 consecutive releases we don't end up updating this repo, we would then just cut the cord and use the staged repo on its own. (for example).

(Don't want to decide now basically)

thanks,

Dims

[Benjamin Elder]

Have we ever in-place converted a staging repo?

I think we should decide now, because it impacts the versioning scheme.

Staging repo auto-version-tags won't make much sense to continue if we try to cut the cord.

We could abandon and come up with a new name, but that seems bad.

[Davanum Srinivas]

Nope. we haven't. this would be the first time. we talked about CRI repo for sure, but no.

[Joe Betz]

+1

It sounds like all the constants migrating to this model will be stable API-related constants? My only high level thought is that we have a LOT of constants in the codebase that don't need to be migrated to this module, so having clear guidelines for what belongs in this module will be valuable.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CAOZRXm-iT84Goza6Xorr5T9UTsUGGpFye8EbAv8BQBEedMUbJg%40mail.gmail.com.

[David Eads]

Why have a separate constants repository instead of having constants related to our API defined in k8s.io/api?

DE2

To unsubscribe from this group and stop receiving emails from it, send an email to sig-api-machin...@kubernetes.io.

[Davanum Srinivas]

it requires apimachinery - https://github.com/kubernetes/api/blob/master/go.mod#L10 

[David Eads]

But why would someone who doesn't use k8s.io/api use a constant like the one linked for kube API validation?  And why would we want to provide constants that aren't related to our API?

DE2

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CANw6fcHzKkV1i_MQ584NeELZAr9iH1vXvQt%2BobYXP5k7XqSTwQ%40mail.gmail.com.

[Davanum Srinivas]

David,

I would love it if you could please poke at it and come up with alternatives :) 

thanks,

Dims

[Tim Hockin]

In theory someone might want the constants in a controller or client which only uses custom resources, making the k8s.io/api dep not necessary?

Practically, there might be value is using those same constants in other libs like k8s.io/utils/net using the same values for protocols or IPFamilies but that is a weak argument.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CANw6fcFD42WskH7n_X5Yv7hmgf9bwk-%2B%2BefCTrJ2chUNCGCygg%40mail.gmail.com.

[David Eads]

 In theory someone might want the constants in a controller or client which only uses custom resources, making the k8s.io/api dep not necessary?

That person would be fine using k8s.io/apimachinery where the current example lives.

DE2

[Tim Hockin]

Personally, I kind of feel like metav1 and friends should ALSO live in k8s.io/api but that's a different discussion :)

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CAFS1MjKqt2auKaiDOaoA%3Drun56qMfbziR50SUUPyw8QwhCr9tg%40mail.gmail.com.

[David Eads]

So from the original list

- rfc/ — length constants for Kubernetes name-like fields (docs describe the Kubernetes grammars, not strict RFC compliance; aligned with KEP-5311 and kube-openapi#384).
- limits/ — LabelValueMaxLength, LabelKeyMaxLength, FieldManagerMaxLength.
- labels/, annotations/, taints/ — well-known keys. Identifiers drop the package-name prefix (labels.Hostname, not labels.LabelHostname).

limits, labels, annotations, and taints are all tightly associated with our k8s.io/api.  Anyone using them with our API, already depends on k8s.io/api, so they could live there.  Anyone using them with just CRDs, already depends on k8s.io/apimachinery, so that dep chain doesn't really get notably deeper.  Is anyone using them without our API and without CRDs?  If so, what are they doing with them?

rfc constants seem like an odd thing other projects to rely on kube for if they aren't working with our API or CRDs.

I may have missed the example in the messages, but do we have a concrete example of the project that wants to rely on these kube-API associated details but does not want to rely on kube API and apimachinery libraries?

DE2

[Davanum Srinivas]

Please see:

https://github.com/kubernetes/kubernetes/issues/127888

[David Eads]

Given the scope of the proposed change, I'm not seeing the value in moving a few constants before the far larger change is agreed.  I'm in favor of a client and API that allows co-existence of multiple versions without conflict where the version of the client is tied to client behavior not API version.  At first blush, I'd create a brand new client project and possibly a brand new (or generated?) API than adapt what we have.

That idea is an interesting one, but a constants repo is not what is holding that back.

DE2

[Davanum Srinivas]

I was afraid you were going to say that when i posted that issue url :) FWIW, i think that's one example and we should not be over indexing on just that one. we can talk more in sig-arch call.

[Patrick Ohly]

"'David Eads' via sig-architecture" <sig-arch...@kubernetes.io>

writes:

> Given the scope of the proposed change, I'm not seeing the value in moving
> a few constants before the far larger change is agreed.

I'm with David here. As I said in
https://github.com/kubernetes/kubernetes/issues/127888#issuecomment-2395538443,
doing just one small step without knowing what the next ones are doesn't
really help us - it creates work and churn and might ultimately be
futile.

> I'm in favor of a
> client and API that allows co-existence of multiple versions without
> conflict where the version of the client is tied to client behavior not API
> version. At first blush, I'd create a brand new client project and
> possibly a brand new (or generated?) API than adapt what we have.

While interesting, I'm wary about how much effort that'll be and the
lack of adoption. If it's completely incompatible with the current
client-go, then all of the existing code will continue to use client-go.

I prefer to investigate splitting up client-go into different modules,
with the exact same import paths and package APIs. That's expected to be
completely transparent to consumers, as discussed in the issue. Tackle
the hard problems first, not the simple ones!

Once we have that, then we may be able to identify modules which really
benefit from severing the apimachinery dependency while still being
useful for apps on their own.

--
Best Regards

Patrick Ohly
Cloud Software Architect

[Lubomir I. Ivanov]

> Concretely, k8s.io/api/resource/v1 pulls in the entirety of util/validation — regex engine, error aggregation, the whole surface — for a single integer (issue #127889).

there is also the aspect that moving constants will break consumers.

i'd just fork the constants and add comments in all locations (origin
& forks). on origin, enumerating the consumers on a best effort, and
on the forks explaining to keep this in sync with origin to pulling
entire modules. linters can help here too.

lubomir
--

[Lubomir I. Ivanov]

> with origin to pulling

* instead of pulling

lubomir
--

[Davanum Srinivas]

"moving constants will break consumers." i think i left the old ones there, if i missed something happy to fix.

[Lubomir I. Ivanov]

ok, i see what you did in the PR, it's just a reference ALA 'const
PoolNameMaxLength = rfc.DNS1123SubdomainMaxLength'
where 'rfc' is a package from the new `constants` module. this works
nicely and it doesn't 'move' constants, per se.
so +1.

lubomir
--

[Tim Hockin]

A little copy is better than a little dependency.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-architecture/CAGDbWi9rEwg8q7%2BBy-YBaxpfsnrrzPuPjK%2BiL%3D00BsKvenOseg%40mail.gmail.com.