Feature: Allow to pass selectableFields for CRD definition

[Danil-Grigorev]

Motivation

KEP 4358 allows to define new field - selectableFields within the CRD schema, enabled by default (beta) in 1.31.

Solution

Expose the selectable key in kube() macro, allowing to provide a set of values into generated CRD.

Example:

#[kube(
    group = "clux.dev",
    version = "v1",
    kind = "Foo",
    namespaced,
    selectable = "spec.key",
    selectable = "spec.name"
)]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.2%. Comparing base (95cf702) to head (9ed7f88).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1605     +/-   ##
=======================================
+ Coverage   75.2%   75.2%   +0.1%     
=======================================
  Files         82      82             
  Lines       7335    7342      +7     
=======================================
+ Hits        5514    5521      +7     
  Misses      1821    1821             

Files with missing lines	Coverage Δ
kube-derive/src/custom_resource.rs	81.2% <100.0%> (+0.8%)	⬆️
kube-derive/src/lib.rs	0.0% <ø> (ø)
kube-derive/tests/crd_schema_test.rs	96.9% <ø> (ø)

[clux]

Looks great. Nice KEP also, had missed this! Maybe add a quick markdown header for it in the lib.rs file so people can discover it?

[Danil-Grigorev]

Looks like CI failures are unrelated to the PR.

[clux]

Looks like CI failures are unrelated to the PR.

indeed. dunno what's up with the rustls build atm. C library type errors :|

[aviramha]

I think this breaks the Kubernetes version guarantee - requires openapi to upgraded to 1.31 to compile kube-rs as a dependency. @clux

[clux]

oops, good spot. we need to version gate it!

[aviramha]

can we rollback this until it's version gate? can't build main as dependency :(
also, perhaps the dev requirement should adhere to the policy so we can guarantee better?

[Danil-Grigorev]

It should not break CRD generation for pre 1.31 clusters if the selectable is not specified @aviramha

[aviramha]

It should not break CRD generation for pre 1.31 clusters if the selectable is not specified @aviramha

I think there's some ambiguity whether the MK8SV is runtime or compilation, in my case, if we use "earliest" on k8s open api we can't compile this commit.

[Danil-Grigorev]

Ah, I suppose I see where your problem is https://github.com/kube-rs/kube/pull/1605/files#diff-6750cfa2314830da21402810282fd1a9a9f270c217c393e03a2c04e1b2735d10R450, makes sense.

[clux]

i think you can use a https://docs.rs/k8s-openapi/latest/k8s_openapi/macro.k8s_if_ge_1_30.html around an if that factors out the fields: Vec... ^

@aviramha: a bit off-topic, but is there any reason you don't use latest? you generally don't lose anything by going newer.

[aviramha]

i think you can use a https://docs.rs/k8s-openapi/latest/k8s_openapi/macro.k8s_if_ge_1_30.html around an if that factors out the fields: Vec... ^

@aviramha: a bit off-topic, but is there any reason you don't use latest? you generally don't lose anything by going newer.

It's pretty much the first dependency we added, and earliest felt safest. I think it still makes sense, so devs won't try to use API that isn't compatible with older clusters by accident.

[Danil-Grigorev]

Thanks for the pointer @clux, was about to ask how the version gating done elsewhere, will prepare a PR in a moment :)

[clux]

also had a quick look, i think this will do it: #1609