Infinite loop on certain misconfiguration #50
Labels
Container
Issues or pull requests relevant for Team 2: Container Infra and Tooling
Comments
janiskemper
added
the
Container
matofeder
added a commit
to SovereignCloudStack/cluster-stack-provider-openstack
that referenced
this issue
Jan 12, 2024
An infinite loop may occur on certain misconfigurations, e.g., if the Github/OpenStack client is misconfigured. In such cases, the operator correctly sets a condition that can be used for the user to debug. However, it also returns an error, which means that the operator reconciles immediately again. There is no need to return the error, as the user checks the conditions stored in the status of the objectrather than potential error logs. The controller's default syncPeriod, set to 5 minutes, ensures that the controller will try again later to check whether the failed state has been resolved. See related SovereignCloudStack/cluster-stack-operator#50 Signed-off-by: Matej Feder <matej.feder@dnation.cloud>
matofeder
added a commit
to SovereignCloudStack/cluster-stack-provider-openstack
that referenced
this issue
Jan 15, 2024
An infinite loop may occur on certain misconfigurations, e.g., if the Github/OpenStack client is misconfigured. In such cases, the operator correctly sets a condition that can be used for the user to debug. However, it also returns an error, which means that the operator reconciles immediately again. There is no need to return the error, as the user checks the conditions stored in the status of the objectrather than potential error logs. The controller's default syncPeriod, set to 5 minutes, ensures that the controller will try again later to check whether the failed state has been resolved. See related SovereignCloudStack/cluster-stack-operator#50 Signed-off-by: Matej Feder <matej.feder@dnation.cloud>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
/kind bug
What steps did you take and what happened:
If the Github client is misconfigured, e.g. by a secret that is not working, the operator correctly sets a condition that can be used for the user to debug. However, it also returns an error, which means that the operator reconciles immediately again. As nothing has changed, it will run into the same issue again.
What did you expect to happen:
There is no need to return the error, as the user checks the conditions stored in the status of the object rather than potential error logs. Even if a log should be produced, it should happen only once the first time the error occurs. Instead of returning the error, we can return nil and don't run into an endless loop.
Anything else you would like to add:
This pattern might exist somewhere else as well and should be always addressed in the same way: setting the condition appropriately and returning nil.
The text was updated successfully, but these errors were encountered: