Anexia Provider: Utilize Creating state instead of blocking Create call

[marioreggiori]

What this PR does / why we need it:

The machine-controller calls the providers Create method sequentially and only starts with the provisioning of another instance after Create returned without any errors. This PR changes the

• Create method to not block until the VM provisioning has completed
• Get method to check via the instance status whether InstanceID and ProvisioningID are set

and utilizes the Creating state until the VM is ready.

This reduces the provisioning duration of node pools with more than one replica significantly as there are now only a couple of seconds (~10s) between the provisioning starts.

Which issue(s) this PR fixes (optional, in fixes #<issue number> format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Optional Release Note:

[LittleFox94]

Oh wow, that looks really nice!

I seem to remember we had problems with parallel IP reservations in the past and this being the reason to serialize machine creation - did you test this or know anything more about it?

[marioreggiori]

Thanks 🙂

I seem to remember we had problems with parallel IP reservations in the past and this being the reason to serialize machine creation - did you test this or know anything more about it?

I only know about this problem from the ticket related to this PR. But this also shouldn't be an issue as long as the Create method (which indirectly reserves the address) is called sequentially, right? I created two replicas=3 node pools with the problem in mind and couldn't find anything out of the ordinary.

[LittleFox94]

Thanks slightly_smiling_face

I seem to remember we had problems with parallel IP reservations in the past and this being the reason to serialize machine creation - did you test this or know anything more about it?

I only know about this problem from the ticket related to this PR. But this also shouldn't be an issue as long as the Create method (which indirectly reserves the address) is called sequentially, right? I created two replicas=3 node pools with the problem in mind and couldn't find anything out of the ordinary.

Could we, just to be safe, have a mutex around the "Reserve IP" and "Create VM" operation? Locking before reserving the IP, unlocking once the VM creating request is sent and progress is at least at 10% or something? How would this affect the timing?

[marioreggiori]

Thanks slightly_smiling_face

I seem to remember we had problems with parallel IP reservations in the past and this being the reason to serialize machine creation - did you test this or know anything more about it?

I only know about this problem from the ticket related to this PR. But this also shouldn't be an issue as long as the Create method (which indirectly reserves the address) is called sequentially, right? I created two replicas=3 node pools with the problem in mind and couldn't find anything out of the ordinary.

Could we, just to be safe, have a mutex around the "Reserve IP" and "Create VM" operation? Locking before reserving the IP, unlocking once the VM creating request is sent and progress is at least at 10% or something? How would this affect the timing?

Re "affect on timing": I'd have to test this, as I'm not sure how linear the progress returned by the engine is.

I think a mutex guarding provider.Create (which also includes the reservation) wouldn't hurt. But I fear that we or the machine-controller could easily lock provisioning indefinitely by accident if we only release the mutex at >=10% progress.

[LittleFox94]

Let's add a mutex around the IP reservation call, reading through old tickets this should be enough :)

[LittleFox94]

we should probably give this another name, given how people outside Anexia cannot see this ticket and this is going upstream

[LittleFox94]

merged upstream as kubermatic#1483