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?)
InGame-unalkalkan
commented
4 years ago
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
MaintenanceWindowresource in a namespace, and have a controller take action on a bunch of other resources.For example, I'd like it to:
matchLabelsobject and set theirspec.replicas = 0, andspec.replicasto the original value when theMaintenanceWindowobject is removed.I implemented a flavor of this via a DecoratorController with no
attachmentsthat 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 fullchildrenarray 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!