perf(creation): remove polling from creation #249
Conversation
… be used on async reasons
This doesn't seem acceptable as for any async error that fails we will have an additional 14 minutes for a retry(Assuming 1m for create to fail) vs before it was 2s 4s 8s 16s 60s retries on nodeclaim create. Is there a better design for dealing with the long running error messages? Can we check async for those error messages in a separate goroutine not blocking the main Create thread and report back the status, if it fails we delete the nodeclaim or something like that? |
| if val, ok := nodeClaim.Labels[corev1beta1.NodePoolLabelKey]; ok { | ||
| tags[NodePoolTagKey] = &val | ||
| } | ||
| nodePoolLabel := nodeClaim.Labels[corev1beta1.NodePoolLabelKey] | ||
| tags[NodePoolTagKey] = &nodePoolLabel |
There was a problem hiding this comment.
Why did we change this?
There was a problem hiding this comment.
Oh, good catch. This is unrelated to the change.
Pretty sure its a bug I found months back. Will separate it out into a new PR.
Fixes #
Description
Currently the Azure Karpenter Provider is not able to leverage budgets for doing multi-Drift, since the core logic only looks to start a second node Drift, after the first create responds back with its Provider ID. Since we wait for the actual Async operations to Azure to complete before moving on, this means that we are delaying this response, and losing out on the possible asynchronous multi-Drift functionality within budgets.
This change removes our Polling (waiting) on the create calls to allow us to respond back with the Provider ID quickly, and take advantage of multi-Drift.
We still track the vm create async errors internally, and asynchronously to track and mark unavailable offerings.
Note: for creations that fail asynchronously it will fall back on registerationTTL to clean up any failed instances, which is currently set at 15min:
How was this change tested?
E2E run:
Also, did multiple manual tests in code spaces.
*
Does this change impact docs?
Release Note