The ~"group::runner" Fleet team introduced creating runners with authentication tokens rather than registration tokens in 15.9 - see this epic https://gitlab.com/groups/gitlab-org/-/epics/7663. We obtained a large amount of feedback from users who tried out the new flow. This epic contains issues and child epics to help resolve the issues identified. The main themes from the feedback are as follows: ### Users are frustrated that their existing automation is broken and now they have to interact with the UI Example quotes: > Runners must be configured in a project first (via UI) before getting a new machine "registered" to any projects. This was concerning because we are using EC2 instances that automatically scales and therefore it would be difficult to get them registered to our projects if we could not predict/obtain a runner configuration's authentication token. > I agree with the seeming addition of unnecessary complexity - I do not like that I'm now restricted to preconfiguring the runners in the UI versus how I'm doing it now by setting tags via the API - what I have now allows me to copy/paste/edit desired config in a Terraform script that then deploys across all AWS accounts. ### Users are confused by the new UI This includes cases when they are: * creating runners by reusing authentication tokens. * creating runners using Docker or Kubernetes. * reviewing runner stats at a glance. * managing runner managers. > Questions that I have:\ > If you can't use the new registration process for Kubernetes, why are they displayed in the UI nearly identically to the "Operating systems" options?\ > If you can use the new registration process for Kubernetes, why isn't Kubernetes selectable? > Correct me if I wrong, but when I tried the same thing just recently - using the same token will only lead to overwriting the runner configuration, it seems to me I cant register 2 or more runners using the same authentication token? I'll end up with a latest instance registered being the actual runner registered only > This may explain it better:\ > I upgraded the helm chart this morning, which is why we have 2 runners with different versions.\ > You can see there is an offline runner for every day the AKS cluster is brought up, and its not re-using the existing (same token, using the same manager). Is this the expected behaviour?\ > There’s never more than 6 days worth of offline runners, so Gitlab must eventually housekeep these? ### Users are confused and frustrated when trying to use Helm charts > The new terraform resource gitlab_user_runner available in the 16.3 release works properly.\ > Since we were already wrapping our deployment of the Gitlab runner helm chart in Terraform using a helm_release resource this change has meant adding an additional gitlab_user_runner resource and referencing it's access token in the helm_release instead of the a registration token. For those deploying helm directly this is still awkward since it requires a command outside of the helm setup. We could take advantage of a helm chart based solution as well, but at least this is workable without additional manual setup. > However, this is not at all what happens. Replica number 2 is unable to attach to existing child pods. It is even incapable of sharing the "concurrent" settings found in the ConfigMap. Consequently, for a namespace designed for 30 jobs and with two replicas of the runner manager, there can be up to 60 pods.\ > I'm struggling to grasp the concept of grouped runners; I don't have scenarios where this could be beneficial. I'm confused about this feature, just as I am about the possibility of having multiple replicas for a Kubernetes-type runner manager. :sparkles: [See this Figjam for all feedback groupings](https://www.figma.com/file/ngYlabfu1nU7phTq2OdcpG/Runner-registration-feedback?type=whiteboard&node-id=4%3A1196&t=yxChXdPkVcarLXfM-1)