Feature Request: Support intentional orphaning of CompositeController children

[roblg]

Request

Support CompositeControllers intentionally orphaning children (specifically, children that they've adopted by label selector), setting up a form of "temporary adoption".

Use Case

I'd like to be able to create a single custom MaintenanceWindow resource in a namespace, and have a controller take action on a bunch of other resources.

For example, I'd like it to:

• take all Deployments matching a particular matchLabels object and set their spec.replicas = 0, and
• reset spec.replicas to the original value when the MaintenanceWindow object is removed.
• maybe do some other things (automatically reroute istio VirtualService backends to a maintenance window page or something?)

I implemented a flavor of this via a DecoratorController with no attachments that calls out to kubectl, and it's functional, but I realized as I was testing it that CompositeController can almost do this natively, with one gotcha: it deletes its children when the finalizer is finished, even if I keep returning the full children array from the finalizer hook.

From the perspective of something like ReplicaSets, which are kind of CompositeController-ish, it makes sense to delete any adopted pods, but I'm wondering if there's a place for "temporary adoption" by a controller as well. (Or perhaps I'm missing a more obvious way to tackle this problem?)

Thanks for your consideration!

[InGame-unalkalkan]

+1