-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Use of log.Fatalf in resourcemanager packages #432
Comments
leaving the log.fatal statements in test files... makes sense there |
replace fatalfs in packages with errors that get returned instead |
@frodopwns, cc @jananivMS , any thought to reproduce the issue on cosmosDB and appInsights? Any thought? func getCosmosDBClient() documentdb.DatabaseAccountsClient { |
@buhongw7583c I dont think we will be able to repro some of these errors to happen like in this case, we only fail here if getting an authorizer fails. You could follow the same pattern as we use for other clients. |
Describe the bug
Some clients for azure resources are exiting due to
log.Fatalf
calls which runsos.Exit(1)
. This causes the service to exit and leads to unreachable code.eg.
https://github.com/Azure/azure-service-operator/blob/master/pkg/resourcemanager/storages/storage.go#L73
To Reproduce
manually create a storage account, then create that same account using the operator
operator will exit with
Expected behavior
Method returns error where it can be logged and the operator can decide to re-queue if necessary
Additional context
This happens in other files and all should probably be removed
The text was updated successfully, but these errors were encountered: