Make it easier to get an Api for a DynamicObject

[nightkr]

Would you like to work on this feature?

None

What problem are you trying to solve?

There's currently a lot of ceremony around getting an Api corresponding to a DynamicObject that you have got from somewhere, so that you can actually interact with it:

// assuming object: &DynamicObject, kube: &kube::Client, discovery: &kube::Discovery
let type_meta = object.types.as_ref().unwrap();
let (group, version);
match type_meta.api_version.split_once('/') {
    Some(gv) => (group, version) = gv,
    None => (group, version) = ("", &type_meta.api_version),
};
let gvk = GroupVersionKind {
    group: group.to_string(),
    version: version.to_string(),
    kind: type_meta.kind.clone(),
};
let (dyntype, _) = discovery.resolve_gvk(&gvk).unwrap();
let api = match &action.object.metadata.namespace {
    Some(ns) => {
        kube::Api::<DynamicObject>::namespaced_with(kube.clone(), ns, &dyntype)
    }
    None => kube::Api::<DynamicObject>::all_with(kube.clone(), &dyntype),
};
// *Finally* we can use `api`

Describe the solution you'd like

There's a spectrum of options here, all the way from adding individual methods to go from DynamicObject -> GroupVersionKind and an Api<DynamicObject> constructor that takes an optional namespace, to adding a full Api::from_dynamic_object helper that abstracts out the whole ride.

Personally I'd focus less on Api for now since it should be less important going forward (#1375 etc), though #1375 is not enough to make it completely irrelevant yet.

Describe alternatives you've considered

See above

Documentation, Adoption, Migration Strategy

No response

Target crate for feature

kube-client

[clux]

would it make sense to have a discovery.resolve_object(&object) which does all the stuff you have there - before Api - and returns the result of resolve_gvk?

[nightkr]

That could be fair.

Thinking about it a bit more, discovery.resolve_typemeta(&object) would have access to everything we care about + enable custom dynamic types.

[clux]

yeah, that could be nice.

looking into it a bit more, we do also have an intermediate thing here : GroupVersionKind::try_from(&typemeta) in

kube/kube-core/src/gvk.rs

Lines 42 to 48 in 52b3fd8

	impl TryFrom<TypeMeta> for GroupVersionKind {
	type Error = ParseGroupVersionError;
	fn try_from(tm: TypeMeta) -> Result<Self, Self::Error> {
	Ok(GroupVersion::from_str(&tm.api_version)?.with_kind(&tm.kind))
	}
	}

[nightkr]

Oh, I missed that actually (in general, I'd argue that From/TryFrom tend to surface very poorly in docs).