Add typed scale argument to derive macro

[Techassi]

Motivation

Customizing the scale subresource via #[kube(scale = r#"{}"#)] can feel very out-of-place and requires writing a raw JSON string. In addition, this can lead to a very long line, eg:

#[kube(
    version = "v1alpha1",
    kind = "MyScaler",
    namespaced,
    scale = r#"{"specReplicasPath": ".spec.replicas", "statusReplicaPath": ".status.replicas", "labelSelectorPath": ".spec.labelSelector"}"#
)]
struct ScalerSpec {}

Solution

This allows customizing the scale subresource by providing key-value items instead of a raw JSON string. For backwards-compatibility, it is still supported to provide a JSON string. However, all examples and tests were converted to the new format.

#[kube(
    version = "v1alpha1",
    kind = "MyScaler",
    namespaced,
    scale(
        specReplicasPath = ".spec.replicas",
        statusReplicaPath = ".status.replicas",
        labelSelectorPath = ".spec.labelSelector"
   )
)]
struct ScalerSpec {}

[codecov]

Codecov Report

Attention: Patch coverage is 75.92593% with 13 lines in your changes missing coverage. Please review.

Project coverage is 75.9%. Comparing base (07b7891) to head (57e9c4e).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
kube-derive/src/custom_resource.rs	76.0%	13 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1656     +/-   ##
=======================================
+ Coverage   75.8%   75.9%   +0.1%     
=======================================
  Files         84      84             
  Lines       7626    7679     +53     
=======================================
+ Hits        5776    5822     +46     
- Misses      1850    1857      +7     

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

[clux]

Hey there. Thanks for this! Apologise for the delay.

I think this makes sense, given you've made it non-breaking, but ideally the dependency on the openapi crate should be severed if it's just for the interface. Have added a few suggestive comments.

[Techassi]

Apologise for the delay.

No worries. I will shortly take a look at your comments. I will also see if we can get rid of the k8s_openapi dependency.

[Techassi]

Sorry for the delayed work on this, but I think I have addressed both of your biggest concerns in d93d708.

[Techassi]

I think this PR is ready. Any objections merging this @clux?

[clux]

Any objections merging this

Ahh, sorry, I forgot about this. Had a busy month. Yes, this looks sensible. I had a quick re-look over, and one nit, maybe. See if you agree. Otherwise it's all good. Happy for you to iteate more if you have other ideas.

I think the thing that made this go to the back of my mind for a while was I wasn't sure about the complexity tradeoff here about supporting two modes if we had no good way to deprecate the old one. But I suspect we can gradually phase out the old raw string stuff and simplify this down the line anyway.

[Techassi]

I wasn't sure about the complexity tradeoff here about supporting two modes if we had no good way to deprecate the old one. But I suspect we can gradually phase out the old raw string stuff and simplify this down the line anyway.

Yes, that is indeed a tradeoff. Luckily, we can get rid of most of the added code once we deprecate the old way:

• We won't need the from_string implementation, because we don't need to parse the JSON string anymore.
• We can drop the custom from_list implementation and just use #[derive(FromMeta)] on Scale.

[Techassi]

Let me know if this answer is satisfactory: #1656 (comment). If so, we can move forward and merge.

[clux]

All good. Ill merge. Thank you very much!

[Techassi]

Alright, cool. Thank you as well!