TODO - More resources to add about kdash HOT 11 CLOSED

oh and another reason exclude did not work is that not all kinds from a group is implemented so excluding by group will also remove the Kinds I actually want to load :( Would be nice if exclusion can be done by Kind as well

from kdash.

Ah, if you need to do it more granularly than by group then you're not saving api requests anyway so you may as well do the filtering you are already doing in that case.

from kdash.

btw CORE_GROUP is just a shorthand to refer to the apiVersion: v1 resources (which doesn't have a group)
so CORE_GROUP is ""

from kdash.

A Generic view would be nice - based on CRDs e.g.

• prometheus-operator: Prometheus,ServiceMonitor,PodMonitor, PrometheusRule, alertmanager,alertmanagerConfig
• logging-operator: ClusterFlow,Flow,ClusterOutput,Output
• fluxcd: GitRepository,HelmRepostory, Kustomize, HelmRelease
• cert-manager: ClusterIssuer, Issuer, CertificateRequest, Request, Challanges
• traefik: Middleware, IngressRoute
• many more

from kdash.

@genofire Yes would be nice but the initial infra for that probably would need some refactoring of the current codebase and unfortunately, I don't have enough time for that. If you or someone else wanna take a shot, I'll welcome it.

from kdash.

@clux do you think it is feasible to get all the resources on the cluster using api-resources and then iterate through them and build kube::core::DynamicObject using the Api::all_with method and GroupVersionKind or something similar at runtime? I tried to play around with that but my Rust foo is not good enough it seems and got stuck at type mismatch and complex trait definitions

from kdash.

..should is possible for you to display arbitrary dynamic resources, yep. have enough on my plate atm, but can offer some points:

1. KubeResource impls like this should be easy enough to replace in, probably something like:

struct DynamicObjectWrapper(DynamicObject)
impl KubeResource<Value> for DynamicObjectWrapper {
  fn get_k8s_obj(&self) -> &Value {
    &self.0.data
  }
}

2. you'd have to keep around discovery information for the types you wanted to show (or fully constructed Api objects), because you have these generic helpers to fetch that relies on DynamicType: Default in

   kdash/src/network/kube_api.rs

   Lines 364 to 423 in fee3d4b

   	/// calls the kubernetes API to list the given resource for either selected namespace or all namespaces
   	async fn get_namespaced_resources<K: ApiResource, T, F>(&self, map_fn: F) -> Vec<T>
   	where
   	<K as ApiResource>::DynamicType: Default,
   	K: kube::Resource<Scope = NamespaceResourceScope>,
   	K: Clone + DeserializeOwned + fmt::Debug,
   	F: Fn(K) -> T,
   	{
   	let api: Api<K> = self.get_namespaced_api().await;
   	let lp = ListParams::default();
   	match api.list(&lp).await {
   	Ok(list) => list.into_iter().map(map_fn).collect::<Vec<_>>(),
   	Err(e) => {
   	self
   	.handle_error(anyhow!(
   	"Failed to get namespaced resource {}. {:?}",
   	std::any::type_name::<T>(),
   	e
   	))
   	.await;
   	vec![]
   	}
   	}
   	}
   	async fn get_resources<K: ApiResource, T, F>(&self, map_fn: F) -> Vec<T>
   	where
   	<K as ApiResource>::DynamicType: Default,
   	K: Clone + DeserializeOwned + fmt::Debug,
   	F: Fn(K) -> T,
   	{
   	let api: Api<K> = Api::all(self.client.clone());
   	let lp = ListParams::default();
   	match api.list(&lp).await {
   	Ok(list) => list.into_iter().map(map_fn).collect::<Vec<_>>(),
   	Err(e) => {
   	self
   	.handle_error(anyhow!(
   	"Failed to get resource {}. {:?}",
   	std::any::type_name::<T>(),
   	e
   	))
   	.await;
   	vec![]
   	}
   	}
   	}
   	async fn get_namespaced_api<K: ApiResource>(&self) -> Api<K>
   	where
   	<K as ApiResource>::DynamicType: Default,
   	K: kube::Resource<Scope = NamespaceResourceScope>,
   	{
   	let app = self.app.lock().await;
   	match &app.data.selected.ns {
   	Some(ns) => Api::namespaced(self.client.clone(), ns),
   	None => Api::all(self.client.clone()),
   	}
   	}
   	}

   and this wouldn't work with discovered types (since they don't have a trivial DynamicType). These are usually kept in examples as ar. See https://github.com/kube-rs/kube/blob/main/examples/dynamic_api.rs . Might be easiest to keep around fully constructed Api objects from discovery and look those up at runtime instead.

3. you won't have a sensible thing to use to display columns easily in the ui. you'd have to cross reference with the crd schema and look at printer columns if you wanted to do this, which means you'd have to cache crds in the app, but that's probably not a big deal

4. kube::discovery can be configured to exclude the common types you've already implemented. meaning you shouldn't need to run into duplicates from discovery with your catch-all dynamic, and you'd speed up the process a bit

5. discovery takes a little bit of time (the api requires a lot of iteration). caching the discovery result would be better for a snappy CLI. there's an open issue for this in kube, but no one has really volunteered for it.

from kdash.

@clux Thanks for the info 🙏 . Its really helpful. I'll try to cook something up based on this and see how far I get

from kdash.

@clux I built something based on your suggestion fb4b4c4

It only shows name, namespace and age in columns for now. Maybe in the future I can cross ref with CRDs to find other columns to show

from kdash.

Hey, nice. That was quick! Code wise looks very sensible to me from a quick scan.

Minor point; you might be able to make the discovery exclusion a little less hard codey by doing https://docs.rs/kube/latest/kube/discovery/struct.Discovery.html#method.exclude then giving it the CORE_GROUP, plus the main other other groups that you definitely specialise (authorization, apps, etc). Then you won't even ask the api to discover these, plus you'll have a clearer delineation boundary.

from kdash.

Thanks for taking a look @clux appreciate that. I did try the exclude but wasn't working for the core group. What exactly is the key for that?

from kdash.