How can I have a collection (Vec?) of different Resource objects?

[mortenlj]

I have some code that takes some configuration, and is supposed to return a list of kubernetes resources to create (or replace). The code can create different resources and varying number of resources, depending on the config.

I've tried creating a Vec of Resource, but my Rust skills are not up for the task of figuring out how to do such a thing. I have tried looking for some other way to do this, but I keep comming up short.

Any pointers for how to approach this?

Am I doing something weird, and there is a completely different approach that would work better in Rust?

PS. I'm fairly new to Rust, but have many years of Java, Go and Python experience.

[clux]

Resource is a trait so you would have to do something like Vec<Box<dyn Resource>> ala https://doc.rust-lang.org/rust-by-example/trait/dyn.html if you really wanted to use Resource as the type identifier. EDIT: this won't work, as it's not object safe.

This is imo annoying to deal with though, lots of boxing, and you have to downcast to get the original implementor of the trait back.

You can alternatively give yourself a way to pack, and unpack all the Resource implementors by using an enum ala the multi_watcher example, but if you don't know the types you care about ahead of time, then you its easier to go into the dynamic api with DynamicObject. The kubectl example shows how to apply arbitrary documents.

[mortenlj]

I've tried lots of variants around Vec<Box<dyn Resource>>, but I always seem to get stuck on some consts that prevents creation of trait objects (iirc).

I guess I'll look at DynamicObject some more. I've glanced briefly at it before, but there didn't seem to be a way to create a DynamicObject from a Deployment or Service etc?

I really would like to be able to create the resources using the fully typed structs ...

[clux]

Ah, yeah, boxing Resource won't actually work upon reflection, as Resource is not object safe due to having associated generic params. You'll get errors telling you can't turn it into an object.

If you want typed structs then you kind of need to know the types up front so you can create a mapping (because otherwise how would you know what structs to use). You can create a mapping in many ways; enum suggestion above, DynamicObject with conversions at an early step (e.g. deserialization from a yaml) by matching on apiVersion/kind and deserializing the DynamicObject.data.

However, note that if you need to work on multiple types, then the spec types can't really matter if you want to be generic. So generally;

1. if you are getting a collection of arbitrary objects, then an explicit conversion step allows matching on kinds for specialized logic.
2. if you are getting multiple types of collections from multiple streams / sources, it's often easier to keep multiple vectors around (one for each type explicitly) to avoid having to map things back and forth

there's some info on writing generic code across multiple types in https://kube.rs/controllers/generics/ for controllers

[mortenlj]

However, note that if you need to work on multiple types, then the spec types can't really matter if you want to be generic

Basically, I have a number of "generators", which will generate a number of different Kubernetes resources, i.e. Deployment, Service etc.
I want to collect these resources, and pass them on to a function that applies them to the cluster or writes them to file (or other interesting things like compare with expected output for tests etc.).

I think I have an approach with DynamicObject that will work, but it feels like the conversion from a Resource to a DynamicObject (which I found in a different thread) is a bit of a hack ...

[clux]

You could collect them into separate resources that are typed to specific kinds, but have the processing function be generic;

fn process_object<K: Resource + DeserializeOwned>(obj: &K) {
  // use generic methods on Resource / Deserialize traits to do generic things
}

let deploys: Vec<Deployment> = todo!();
let sts: Vec<StatefulSet> = todo();

for k in deploys {
  process_object(k);
}
for k in sts {
  process_object(k);
}

[SOF3]

Depending on what you actually need to do with the resources, you could create your own trait and implement them for the foreign types (the actual resource objects) depending on your specific object interaction and interpretation requirements. You don't need to use the Resource trait, which is intended for kube's API bounds, not for your own reusability bounds.