Before controller-runtime, people use to manage CRDs via client-go in operators. I think this boils down to CRDs not having an IDL to work with. For a proper spec-driven development, it would be nice if there was an IDL(protobuf or something as simple as that). That'll truly make developing operators polyglot. We could then have the server-stub(Reconcile methods) and client code(CRD clients generated via code-generator) all coming off from the IDL-defined spec
I think rust is also well suited to the async nature of operators more than golang in some respects, especially when defining futures or other await tasks that just a hassle to try and implement in a go routine.
Thanks for the video. Always a great to watch your videos! I am not sure if I would went with applying the CRD in the code. I know it's a demo there is always room to improve or make it different in a "real" project. My idea would be some kind of codegen approach of defining a second binary in the Cargo.toml and linked to a new rustfile calling serde_yaml::to_string(&TopologySpec::crd()).unwrap()) in the main and write this to a yaml. Later apply this to the cluster so the operator is not creating CRDs in code. Again just an idea. :D
Looks like there's an error on line 65 let obs = watcher(topologys, ListParams::default()).applied_objects(); You cannot receive Node updates by watching a Topology resource. The correct one might be: let obs = watcher(nodes, ListParams::default()).applied_objects();
Join our slack and let us know what you think join.slack.com/t/cloudnativeskunkworks/shared_invite/zt-1n7d9puoy-tKH7kEgTK74syR4JUkdK4g
This link is no longer active
To join this workspace, you’ll need to ask the person who originally invited you for a new link.
@@herrwolken Sorry about that, try this one join.slack.com/t/cloudnativeskunkworks/shared_invite/zt-1qh1h3hx2-N3vtNTr3s0BajAZ43k2hiA
I love kubernetes and rust.... this combined was amazing to see
Great video. Rust is really great for writing operators
Before controller-runtime, people use to manage CRDs via client-go in operators. I think this boils down to CRDs not having an IDL to work with. For a proper spec-driven development, it would be nice if there was an IDL(protobuf or something as simple as that). That'll truly make developing operators polyglot. We could then have the server-stub(Reconcile methods) and client code(CRD clients generated via code-generator) all coming off from the IDL-defined spec
I think rust is also well suited to the async nature of operators more than golang in some respects, especially when defining futures or other await tasks that just a hassle to try and implement in a go routine.
Thanks for the video. Always a great to watch your videos!
I am not sure if I would went with applying the CRD in the code. I know it's a demo there is always room to improve or make it different in a "real" project.
My idea would be some kind of codegen approach of defining a second binary in the Cargo.toml and linked to a new rustfile calling serde_yaml::to_string(&TopologySpec::crd()).unwrap()) in the main and write this to a yaml. Later apply this to the cluster so the operator is not creating CRDs in code.
Again just an idea. :D
Sounds like a contribution waiting to happen!
Looks like there's an error on line 65
let obs = watcher(topologys, ListParams::default()).applied_objects();
You cannot receive Node updates by watching a Topology resource.
The correct one might be:
let obs = watcher(nodes, ListParams::default()).applied_objects();