You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 22, 2022. It is now read-only.
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!
The text was updated successfully, but these errors were encountered:
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!
The text was updated successfully, but these errors were encountered: