Rollout-operator currently allows "delayed downscale" if delay has elapsed for all downscaled replicas. For example for following ingest-storage partitions:
maximum timestamp when downscale was initiated is 2024-05-07 04:10:00 UTC, and that tells rollout-operator to wait for delay since this timestamp -- with 13h delay, that would be 2024-05-07 17:10:00 UTC.
However some partitions started to downscale earlier. Specifically partitions 42 – 46 (and corresponding ingesters) could be downscaled after delay since 2024-05-06 12:59:47. With 13h delay that would be 2024-05-07 01:59:47.
This issue is about implementing these earlier downscales for pods "at the end of statefulset" that could be downscaled earlier. In other words, when statefulset is asked to downscale from N to M replicas, we can compute MaxPrepareTimestamp for pods [M..N], [M+1..N], [M+2..N], and if delay has elapsed for any of these, we could downscale given group, even if we can't yet downscale to M pods.
Rollout-operator currently allows "delayed downscale" if delay has elapsed for all downscaled replicas. For example for following ingest-storage partitions:
maximum timestamp when downscale was initiated is
2024-05-07 04:10:00 UTC, and that tells rollout-operator to wait for delay since this timestamp -- with 13h delay, that would be2024-05-07 17:10:00 UTC.However some partitions started to downscale earlier. Specifically partitions 42 – 46 (and corresponding ingesters) could be downscaled after delay since
2024-05-06 12:59:47. With 13h delay that would be2024-05-07 01:59:47.This issue is about implementing these earlier downscales for pods "at the end of statefulset" that could be downscaled earlier. In other words, when statefulset is asked to downscale from N to M replicas, we can compute MaxPrepareTimestamp for pods [M..N], [M+1..N], [M+2..N], and if delay has elapsed for any of these, we could downscale given group, even if we can't yet downscale to
Mpods.