Retry quay.io request on 520 responses #5
Conversation
| accept: :json) | ||
| rescue RestClient::ExceptionWithResponse => err | ||
| return nil if err.http_code == 404 # ignore unknown repos | ||
| if err.http_code == 520 and attempt < MAX_ATTEMPTS |
There was a problem hiding this comment.
Warum versucht ihr es nur bei 520? Das ist ja sogar ein Spezialfall von Cloudflare. Warum nehmt ihr nicht einfach alle 500?
| if err.http_code == 520 and attempt < MAX_ATTEMPTS | |
| if err.http_code >= 500 and attempt < MAX_ATTEMPTS |
There was a problem hiding this comment.
Hm, gute Frage, ich bin unentschlossen. Uns nervt gerade der 520, weil wir wissen, dass das ein temporäres Problem ist und das weggeht, wenn zu einem späteren Zeitpunkt ein erneuter Request kommt. Andere 500 haben wir nicht gesehen und wir wissen auch nicht, wie dann die Situation aussieht. Daher würde ich für den Moment abwarten, bis wir in eine solche Situation kommen und dann bewerten, ob wir alle 500 abfangen.
| rescue RestClient::ExceptionWithResponse => err | ||
| return nil if err.http_code == 404 # ignore unknown repos | ||
| if err.http_code == 520 and attempt < MAX_ATTEMPTS | ||
| sleep(rand(10)) |
There was a problem hiding this comment.
Warum hier ein Zufall beim warten auf den nächsten Versuch? Ich kenne sonst das Pattern, dass mit jedem weiteren Versuch länger gewartet wird (als Optimierung der Gesamtwartezeit). Ich würde daher schreiben
| sleep(rand(10)) | |
| sleep(attempt ** 2) |
Das ** steht für Potenz.
There was a problem hiding this comment.
Das Problem scheint daher zu kommen, dass bei einem Check-Request alle Docker-Nodes gleichzeitig zu quay.io rennen. Das würde sich nicht ändern, wenn alle Nodes deterministisch warten, um dann erneut gleichzeitig bei quay.io anzufragen. Ich will hier bewusst für eine zufällige zeitliche Streuung der Requests über die einzelnen Nodes sorgen.
No description provided.