Add Resource derive macro

[Danil-Grigorev]

Motivation

When working with ConfigMap data, it is often expected to have a specific data structure on the inner content. While defining a CRD is the standard way of resolving the fields validation, it is sometimes not possible or desirable at the moment.

This generally requires a manual conversion via serde, which involves creating a custom structure for the data content, which is only one field away from being a fully replicated ConfigMap or Secret definition (in the context of the problem).

Choosing this direction may require implementing Resource trait manually, which adds to the amount of glue code.

Solution

Provide a Resource derive macro, capable of inheriting Resource trait implementation of the specified upstream object.

The resulting code can look like the following:

use k8s_openapi::api::core::v1::ConfigMap;

#[derive(Resource)]
#[inherit(resource = "ConfigMap", namespaced)]
struct TypedMap {
    metadata: ObjectMeta,
    data: Option<TypedData>,
}

struct TypedData {
    field: String,
}

[clux]

Hey, this is a cool idea.

As a quick first impression, I think it makes sense, although it does not necessarily save much in terms of user code since custom structs can re-use type information with the dynamic api:

kube/examples/dynamic_pod.rs

Lines 25 to 28 in 7ff120a

	// Here we simply steal the type info from k8s_openapi, but we could create this from scratch.
	let ar = ApiResource::erase::<k8s_openapi::api::core::v1::Pod>(&());
	let pods: Api<PodSimple> = Api::default_namespaced_with(client, &ar);

However, there's a reasonable argument for this in terms of complexity, by being able to just use the normal (non-dynamic api) and not have to learn about concepts of erasure.

[codecov]

Codecov Report

Attention: Patch coverage is 56.41026% with 17 lines in your changes missing coverage. Please review.

Project coverage is 75.3%. Comparing base (c975335) to head (4d59964).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
kube-derive/src/resource.rs	40.0%	15 Missing ⚠️
kube-derive/src/lib.rs	0.0%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1565     +/-   ##
=======================================
- Coverage   75.4%   75.3%   -0.1%     
=======================================
  Files         80      82      +2     
  Lines       7284    7323     +39     
=======================================
+ Hits        5489    5511     +22     
- Misses      1795    1812     +17     

Files with missing lines	Coverage Δ
kube-derive/tests/resource.rs	100.0% <100.0%> (ø)
kube/src/lib.rs	88.5% <ø> (ø)
kube-derive/src/lib.rs	0.0% <0.0%> (ø)
kube-derive/src/resource.rs	40.0% <40.0%> (ø)

[Danil-Grigorev]

Yes, agree, I felt that this is explored area already, but at the moment of writing this model looked natural to me. I believe unstable-client features should work with this implementation out of the box.

[Danil-Grigorev]

Hmm, I actually tried using it with similar to dynamic_pod example:

let secret_api: Api<CertSecret> = Api::namespaced_with(
            ctx.client.clone(),
            "cattle-fleet-system",
            ApiResource::erase::<Secret>(&()),
 );

and got:

60 |         let secret_api: Api<CertSecret> = Api::namespaced_with(
   |                                           ^^^^^^^^^^^^^^^^^^^^ the trait `k8s_openapi::Metadata` is not implemented for `CertSecret`

Since the secret follows different model - data vs spec, does it make sense to use generated resource definition?

[clux]

hm, yeah. you'd actually have to use the dynamic api fully for the non-compliant core objects with erase (no Object or derive CustomResource bypass):

let secret_api: Api<DynamicObject> = Api::namespaced_with(
            ctx.client.clone(),
            "cattle-fleet-system",
            ApiResource::erase::<Secret>(&()),
 );

which means secondary Value unpacking, and it does make the dynamic api less attractive for known types. let me review this a bit more properly.

[clux]

couple of minor comments. i like this, particularly after realising the dynamic api is very limited for known types. i do think we can improve the ergonomics a little bit.

(also i am not 100% sure about the name, but we can bikeshed that later)

[clux]

two naming two minor naming things

[clux]

minor comments on new example

[clux]

Maybe a helper comment here:

Suggested change

	let _ca: ConfigMap = client
	.get("kube-root-ca.crt", &Namespace::from(ns.name_any()))
	.await?;
	let _ca: CaConfigMapManual = client
	.get("kube-root-ca.crt", &Namespace::from(ns.name_any()))
	.await?;
	let ca: CaConfigMap = client
	.get("kube-root-ca.crt", &Namespace::from(ns.name_any()))
	.await?;
	for namespace in namespaces {
	let ns = Namespace::from(namespace);
	// Equivalent ways to GET using different structs and different Resource impls
	let _ca: ConfigMap = client.get("kube-root-ca.crt", &ns).await?;
	let _ca: CaConfigMapManual = client.get("kube-root-ca.crt", &ns).await?;
	let ca: CaConfigMap = client.get("kube-root-ca.crt", &ns).await?;

[clux]

last minor nit

[clux]

Looks great. Thank you so much!