Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Welcome @viragvoros! |
|
Thanks @viragvoros 🙂 |
|
@Kumm-Kai So an entirely new retry period variable would be better maybe? |
I would say that both approaches are valid, but at least from our POV, as we are only interested in the |
This PR makes the retry period used when machine creation fails with a
codes.ResourceExhaustederror configurable.PR #981 introduced the
LongRetryretry period (10 minutes) to handle situations where machine creation fails due to exhausted resources. However, in certain environments this retry duration may still be insufficient.To improve flexibility, this PR allows operators to adjust the retry period used specifically for the
ResourceExhaustederror case. The default behavior stays unchanged: if no value is provided as a a command-line flag (--resource-exhausted-retry) to the machine-controller-manager-provider, the controller continues to usemachineutils.LongRetry.Which issue(s) this PR fixes:
Fixes #977
Extends logic introduced in PR #981 to make the retry duration configurable.
Special notes for your reviewer:
The implementation keeps the existing default behavior unchanged:
ResourceExhaustedretry period defaults tomachineutils.LongRetry.--resource-exhausted-retryCLI flag in machine-controller-manager-provider.No changes are required for existing deployments unless operators want to configure the retry duration.
Release note:
@Kumm-Kai @hasit97