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
Currently, say we have 6 Pods running on our original MV/Pipeline Source. We reduce by 3. Our new "upgrading" MV/Pipeline gets created with the scale.min and scale.max set as it's defined in the Rollout spec, so it could be say scale.min=1, scale.max=6. When we create that new one, it will likely come up with 1 Pod by default I imagine and then the autoscaler would kick in after a little time to bump it up to meet the demand.
Per discussion with @whynowy, ideally we shouldn't rely on the autoscaler, but instead create the new one with a temporary scale.min = 3 in the example above, and then reset it later.
Use Cases
When would you use this?
Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
The text was updated successfully, but these errors were encountered:
Summary
Currently, say we have 6 Pods running on our original MV/Pipeline Source. We reduce by 3. Our new "upgrading" MV/Pipeline gets created with the
scale.min
andscale.max
set as it's defined in the Rollout spec, so it could be sayscale.min
=1,scale.max
=6. When we create that new one, it will likely come up with 1 Pod by default I imagine and then the autoscaler would kick in after a little time to bump it up to meet the demand.Per discussion with @whynowy, ideally we shouldn't rely on the autoscaler, but instead create the new one with a temporary
scale.min
= 3 in the example above, and then reset it later.Use Cases
When would you use this?
Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.
The text was updated successfully, but these errors were encountered: