Define deprecation path for old CI runner clients
Current plan
GitLab Runners < 9.0 will stop working as soon as first RC of GitLab 10.0 will be deployed, as it will remove CI API v1.
Old runners on GitLab.com seem to be significantly decreased, so this should not be a big issue for users, but we still want to be sure everyone is properly noticed about it.
This is the current roadmap:
-
Deprecate runners in 9.0 -
Specific blog post (https://about.gitlab.com/2017/04/10/upcoming-runner-changes-for-gitlab-dot-com/) -
Announce old runners will stop to work with 10.0 in the 9.4 release post -
Announce old runners will stop to work with 10.0 in the 9.5 release post -
Collect a list of users that are Masters on projects associated on old runners, and notify them (gitlab-com/infrastructure#1591) -
Make a blog post about it (and tweet two or three times) (blog-posts#363)
All this should happen before the first RC is out.
Original description
Since we are moving to long polling when GitLab-9.0 gets released, we expect to see roughly 40% of the runners benefiting from this improvement automagically.
This means that there is a 60% of runners that are old and will keep hammering, we need to get rid of this.
Roughly this should happen like this:
-
we announce the change loudly (twitter, blog post, whatever else) -
we install the new version and check load to be sure that it is working correctly - scale redis if we need to, etc. -
wait for rollout to complete -
we start throttling harder old runners by checking the user agent (@ayufan will provide the rules we need to identify them), this can happen by injecting delays on them so they only hit us every 59s -
after an arbitrarily defined amount of time we finally start rejecting the old user agents completely. -
we remove the current limitations on valid runners (they should not be affected at all)
Edited by Fabio Busatto