enhancement(stackit): alignment with other providers - #907
Conversation
|
I suspect @robinschneider deliberately did it with a retry for a reason. |
|
@chewi I believe the retry was originally intended to account for the time it takes for the server to be deleted. Since |
We should not remove the retry mechanism, OpenStack consists of multiple APIs, even if an API such as the one for server responds the server is already deleted, the other APIs might not yet know that and are not yet in sync. |
f99d248 to
e6709d2
Compare
Understood. I have restored the retry loop. |
| } | ||
|
|
||
| err := a.client.DeleteKeyPair(ctx, *keyPair.Name).Execute() | ||
| err := a.DeleteKeyPair(ctx, *keyPair.Name) |
There was a problem hiding this comment.
You changed it here, but now gcNetworks, gcSecurityGroups and gcServers are inconsistent.
There was a problem hiding this comment.
updated all the gc functions. Also wrapped the DeleteImage call and updated the error logs.
| } | ||
| if isOpenAPINotFound(err) { | ||
| return nil, ErrorNotFound | ||
| } |
There was a problem hiding this comment.
This was not part of your change, but can you also align the order of the error cheks here?
Make DeleteServer synchronous using `wait.DeleteServerWaitHandler`. consistency of error handling across all deletion methods Simplify garbage collection loops by implementing wrappers. Signed-off-by: Harsh Dahiya <dahiyaharsh2005@gmail.com>
e6709d2 to
b21395f
Compare
3 participants
Stackit: Alignment with other providers
Fixes- flatcar/Flatcar#2287
Testing done
Build was successful.
changelog/directory (user-facing change, bug fix, security fix, update)/bootand/usrsize, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.