mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-12 23:54:01 +09:00
A restarted capi-operator v0.19.0 drops the create events for the provider Deployments it finds already running (kubernetes-sigs/cluster-api-operator#1031). A provider whose Ready condition went False while the operator was down therefore keeps it until that Deployment changes or the informer resyncs, and the first resync after a restart lands two periods later because the handler registers after the informer has listed. With the 10m default that is about 20 minutes, during which capi-providers-core times out on the CoreProvider and everything depending on it waits; every further operator restart starts the clock again. With a one-minute period the same repro recovered 2m02s after the operator took its lease, against no recovery within 4m26s with the default on the same cluster. A resync replays the cache and, with providers in sync, ends in "No changes detected" and an unchanged condition, so it writes nothing to the API server; the operator logged about 15 lines a minute and used 2m CPU and 26Mi of memory. The upstream chart has no value for the flag, so a package patch that make update reapplies adds one, and a bats test holds the rendered argument. Assisted-by: LLM Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
18 lines
658 B
YAML
18 lines
658 B
YAML
cluster-api-operator:
|
|
# A restarted v0.19 operator ignores the provider Deployments it finds
|
|
# running (kubernetes-sigs/cluster-api-operator#1031), so a stale
|
|
# Ready=False on a provider clears only at the first informer resync,
|
|
# two periods after the restart: ~20 min at the 10m default, ~2 min at
|
|
# 1m (both measured). A resync is served from the cache and changes
|
|
# nothing when providers are in sync, so the short period costs no API
|
|
# writes. Applied through patches/sync-period.diff.
|
|
syncPeriod: 1m
|
|
resources:
|
|
manager:
|
|
limits:
|
|
cpu: 200m
|
|
memory: 512Mi
|
|
requests:
|
|
cpu: 100m
|
|
memory: 100Mi
|