Vultr API Rate limiting problem about docker-machine-vultr

[janeczku]

@jmatsushita This is a known issue. Unfortunately Docker Machine's fan-out plugin architecture makes it impossible for the driver to control the global rate of API calls. Operational errors caused by exceeding API rate limits therefore have to be addressed in Docker Machine first and foremost.

It's unfortunate that Vultr does not see the need for action on their part. In fact, they should change their API rate-limit mechanism to some sane per-minute averaged model instead of imposing a ridiculous 2 req/second limit that get's already tripped by synchronously sending 4 API calls in a row.

That being said, the good news is that i am already working on implementing a retry mechanism to deal with rate-exceeded API errors.

[vincent99]

Not a very good answer from them... Checking on a resource that is in a transitioning state every 2 seconds is not an unreasonable use-case. If the queries are that expensive they should have caching on their API layer, not pass their problem down to the clients.

Limiting individual expensive or cacheable calls is one thing, but limiting the entire API to 2 requests/second, particularly with what sounds like a very high-resolution measurement ("2 requests in this second" vs an average like "120 request in the last 60 seconds") is frankly ridiculous.. They're just making it difficult for people to make request to give them money.

(Source: Worked on public APIs for a much larger hosting company in a previous life)

Anyway, I changed the Rancher UI to create one machine at a time, which will probably be good enough to fix it. rancher/ui#605

Also added an option to for createDelayMs that custom driver UIs can use, though someone would have to make one for Vultr to make use of this (see https://github.com/rancher/ui-driver-skel).

[janeczku]

@vincent 😄

[janeczku]

Anyway, I changed the Rancher UI to create one machine at a time, which will probably be good enough to fix it. rancher/ui#605
Also added an option to for createDelayMs that custom driver UIs can use, though someone would have to make one for Vultr to make use of this (see https://github.com/rancher/ui-driver-skel).

Awesome! I think the one machine at a time change will probably be enough to solve this. If not i will take a look at the driver UI skeleton and make one for Vultr.

[janeczku]

Release v1.0.7 implements retry logic for API rate-limit errors.