Multisource/Hierarchical Controller

[jamescarterbell]

Would you like to work on this feature?

maybe

What problem are you trying to solve?

The current controller design is extremely powerful for designing single source watchers, i.e., one controller per record. However, this design as is makes it hard to design a fan-in style system, where one controller might need to operate across multiple records of a given type.

Describe the solution you'd like

For example, imagine the following system:

1. Individual nodes in a cluster are deployed from a backing service that takes rate limited bulk calls.
2. Each node posts it's own health record that can be acted upon to fix node issues.
3. The backing node collection from the service also has a record that shows an accumulated count of healthy nodes.

Ideally, it would be possible to have a set up like so:

let hierarchy_controller = Controller::new(parent_api, Config::default())
   .with_child(child_api, map_child_to_parent)
   .run(reconcile, error_policy, ());

// ...

fn reconcile(parent: ParentType, children: HashMap<String, ChildType>) -> Result<Action> {
  // ...
}

Where reconcile would be called when the parent or children get updated.

In the motivating example, this would enable us to have a reconcile function that gets called whenever any node goes unhealthy, and issue one bulk call against all the currently unhealthy nodes in the reconcile loop, and update the parent record with the number of healthy nodes.

Describe alternatives you've considered

Currently, this would require one controller per node, and one controller for the node collection, with some sort of channel system between the controllers to communicate changes, and some hacky ways to make sure the reconcile loops get run at appropriate times.

This may also not be a good pattern in Kubernetes, but I'm not really sure what major flaws it would have.

Documentation, Adoption, Migration Strategy

No response

Target crate for feature

kube-runtime

[clux]

I'm not sure I understand the setup here.

At a naive reading, this feels to me like a Controller for the parent, with a .watches relation for the child:

let context: Context = todo!();

let hierarchy_controller = Controller::new(parent_api, Config::default())
   .watches_stream(child_stream, map_child_to_parent)
   .run(reconcile, error_policy, context);

// ...
fn reconcile(parent: ParentType, context: Context) -> Result<Action> {
  // TODO: fetch children via an embedded `Store` reader sitting inside `Context`
  // ...
}

but maybe that's not enough for your setup?

[jamescarterbell]

Somehow I misunderstood how watches work, but that example is super enlightening. Thanks! That's basically exactly what I'm looking for with the added fetch step... which seems like a necessary step to enable more complex setups than a single layer hierarchy.