-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
500 errors while registering runners #7
Comments
Ansible only allows to set Did you try running with small amount of forks?
Or, we could write a custom module to handle the registration and retry if necessary. |
I didn't try the small amount of forks. I assume anything that limits the amount of runners that try to register at the same time would do as this seems like a GitLab Server issue though more of a corner case since most people won't be registering multiple runners at the same time. Maybe just a rescue block for the register to re-try/wait & retry? |
Sure, we could check if a rescue block would help. BTW, with what amount of hosts at once you see these issues? Are there any changes if you increase number of threads on the GitLab server? |
This was with trying to register just 2 runners at the same time, just implementing the role separately from any other debops roles. I have not tried increasing the number of threads on the GitLab server since just re-running the playbook registered the second instance (So I've done no further troubleshooting 😄). |
This could all also just be a bug in GitLab proper, but I haven't opened anything with them or looked at the production.log yet. I'll see if I can look at that next time I'm registering more runners. |
I seem to be getting 500 errors somewhat randomly when I am running a playbook with serial: +1 (multiple runners are getting configured at the same time since it is running the tasks in parallel). I am not sure how prevalent it is, but I have seen it at least a few times with my GitLab instances though it is solved by just re-running the playbook.
Would be make sense to add some retry/wait logic around registering with GitLab or would it be better to just deal with it at the playbook level?
The text was updated successfully, but these errors were encountered: