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?)
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:
matchLabels
object and set theirspec.replicas = 0
, andspec.replicas
to the original value when theMaintenanceWindow
object is removed.I implemented a flavor of this via a DecoratorController with no
attachments
that calls out tokubectl
, 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 fullchildren
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!