We'll need a bit more spec on what value that should take. Labels are pretty limited in what they can contain as values.

Another approach might be to add a per-owner label so the key becomes significant. E.g. endpointslice.kubernetes.io/controller-managed: "true"

This allows multiple controllers to think they own a slice, but I am not sure that will be a problem in practice.

Yeah it's hard to come up with the right label(s) here. Would an EndpointSlice ever become managed by a different resource? I think that's unlikely, but if it happened it would involve controllers changing labels that weren't managed by them (or like you mentioned, just letting multiple controllers try to manage a slice).

If we were to switch the important information from the value to the label (endpointslice.kubernetes.io/controller-managed: "true"), what would other related labels look like? As an example, I think kube-apiserver would be a value for endpointslice.kubernetes.io/managed-by for the initial EndpointSlice created/managed by the apiserver, would we want a separate label for that?

Assuming this is all to support additional controllers managing EndpointSlices, I think the controller-managed name might become confusing as it might seem to indicate the difference between an EndpointSlice being managed by any controller vs being created manually.

If I had a 3rd party controller it might be example.com/tims-cool-controller: "true"

re apiserver: whether we use label keys or values, it seems appropriate to denote that the apiserver controls its own endpoints.

By now you should know not to let me name things. endpointslice.kubernetes.io/managed-by-endpointslice-controller: "true" is just as fine. No humans will type this.

My main problem with the simpler proposal is that nothing prevents me from accidentally writing a controller called "cool-controller" and you from doing the exact same.

need to spec this carefully for extension

Should we validate this to only include a set of allowed protocols?

I don't see a need. There are an endless number of "application protocols" that we cannot really capture all of them, so we would likely just see users requesting new protocols added to the set constantly, or force to do other hacks to specify protocol as done today.

My thinking was that either we specify a known list and everything else is "x-whatever" or we use a label-prefix style name (my company.com/foo) or something.

It's ugly wrt conventions around naming (HTTP all caps vs company.com/name all lowercase).

Don't need to solve it here, do need to solve it I'm the API specs. One valid answer is "allow anything" (or a specific character set) and don't validate beyond that.

My thinking was that either we specify a known list and everything else is "x-whatever" or we use a label-prefix style name (my company.com/foo) or something.

It's ugly wrt conventions around naming (HTTP all caps vs company.com/name all lowercase).

Don't need to solve it here, do need to solve it I'm the API specs. One valid answer is "allow anything" (or a specific character set) and don't validate beyond that.

@wojtek-t FYI

This is unfortunate. I was hoping we could force this to embrace CRD.

@lavalamp @erictune @apelisse and all other CRD-ish folks.

IMO it should be possible to statically express more validation for CRDs - common types like "IP address" and "DNS subdomain" should get distinct validation and error messages.

Cross-field validation is more complex, but I'd like to make a case for simple forms of this to be statically expressed too. e.g. if("X", IPAddress, DNSDomain)

cc @DirectXMan12

There's two angles for the "types like IP addresses" -- we can support more "format" values (used in OpenAPI to express complex built-in validation) in kube-apiserver, and some of this can be validated with regexes like:

// this is not correct, but gets the point across
// +kubebuilder:validation:Pattern=`\d{3}\.\d{3}\.\d{3}\.\d{3}`
type IPAddress string

// this would be nice if we could do it
// +kubebuilder:validation:Format=ip-address
type IPAddress string

As for dependent cross field validation, IIRC some of that was explicitly rejected, but it might be worth re-evaluating.

cc @sttts as well

@thockin

would rather make it easier to write validation webhooks than to try to extend OpenAPI to do cross-field validation.

cross-field valdiation is decently rare too, from what I've seen. Common validation for IP addresses and DNS names would be useful though.

Yeah, ok. I'd still like to break this but maybe not yet.

Using CRD sort of required a certain bootstrap sequence:

1. CRD ensured
2. controller startup.

For CRD consumers, there is no good way to wait for a CRD to showed up. Most implementations just die and wait for the restart to try again.

we have to address this in general, anyway