fix race condition in cloud endpoint controller #575
+60
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes a race condition in the cloud endpoint controller. Currently we rely on the status.ID of a could endpoint to inform the controller about whether the cloud endpoint already exists and needs to be updated, or if this is a new custom resource and we need to update the cloud endpoint definition on the server side.
Relying on the status.ID within the controller leads to race conditions when a user (or in this case, the translation from ingresses to endpoints) updates/changes a
CloudEndpoint
resource after it was first created, but before the controller has assigned it a status.ID and updated it. When this happens, the incoming changed but not newCloudEndpoint
still has no status.ID (which will eventually get properly set) and this causes the controller to create multiple different definitions for the cloud endpoint on the ngrok server side and then not being able to properly remove them once theCloudEndpoint
resource is deleted.Instead of doing that, this makes the controller keep an in-memory map of the known
CloudEndpoint
resources so that we can simply check the in-memory map to see if one of them has been created and assigned an ID or not, rather than waiting for the status to be updated and the resource to be re-reconciled again after that.