bug: retry saving helm chart object status #4064
Conversation
if we fail to save the status, specially after installing the chart, we will try to install the chart again during the next reconcile (its Status.Status.ReleaseName will be empty). this pr attempts to mitigate this in two ways: - before updating fetch the newest version of the chart. - retry if it is still on conflict. this may be overkill as it most likely won't fail after we fetch an updated version of the chart but given the importance of this operation we better be safe than sorry. when this bug this solves happens this is what is reported in the chart status: ``` can't install loadedChart ```chart-name```: cannot re-use a name that is still in use ``` Signed-off-by: Ricardo Maraschini <[email protected]>
|
Thanks for the contribution @ricardomaraschini and sorry for taking this long to review this. |
juanluisvaladas
added
backport/release-1.26
|
Git push to origin failed for release-1.26 with exitcode 1 |
|
Validation Failed: {"resource":"PullRequest","code":"custom","message":"A pull request already exists for k0sproject:backport-4064-to-release-1.26."} |
|
Successfully created backport PR for |
|
Git push to origin failed for release-1.27 with exitcode 1 |
|
Successfully created backport PR for |
|
Successfully created backport PR for |
|
Git push to origin failed for release-1.28 with exitcode 1 |
|
Successfully created backport PR for |
|
Git push to origin failed for release-1.28 with exitcode 1 |
|
Git push to origin failed for release-1.29 with exitcode 1 |
1 similar comment
|
Git push to origin failed for release-1.29 with exitcode 1 |
|
Successfully created backport PR for |
|
Git push to origin failed for release-1.26 with exitcode 1 |
|
Git push to origin failed for release-1.27 with exitcode 1 |
|
Git push to origin failed for release-1.28 with exitcode 1 |
|
Git push to origin failed for release-1.29 with exitcode 1 |
twz123
added
bug
Description
if we fail to save the status, specially after installing the chart, we will try to install the chart again during the next reconcile (its Status.Status.ReleaseName will be empty). this pr attempts to mitigate this in two ways:
this may be overkill as it most likely won't fail after we fetch an updated version of the chart but given the importance of this operation we better be safe than sorry.
when this bug this solves happens this is what is reported in the chart status:
Mitigates #4047
Type of change
How Has This Been Tested?
Checklist: