New Registration Flow being rolled out - requires adaption

[duritong]

Gitlab is rolling out a new registration workflow: https://docs.gitlab.com/ee/architecture/blueprints/runner_tokens/index.html#using-the-authentication-token-in-place-of-the-registration-token

This module should adapt to the new flow, since it's already confusing where you get the right token.

[SPFZ]

Maybe helpful: https://docs.gitlab.com/ee/ci/runners/new_creation_workflow.html

[yakatz]

I will try to put together a PR for this

[yakatz]

Just finishing up testing on this, hopefully done in the next day or two.

[tuxmea]

Any update on this? Do you need help?

[baurmatt]

Is there anything todo to get it working? I was able to use the new workflow without module adjustments. I think the only thing that needs to change is:

• Remove deprecated parameters and (un)registration functions
• Rework documentation

[yakatz]

Any update on this? Do you need help?

I am also working on my PhD dissertation, so it is just a question of time. I should get it out in the next few days.

[yakatz]

Is there anything todo to get it working? I was able to use the new workflow without module adjustments. I think the only thing that needs to change is:

• Remove deprecated parameters and (un)registration functions
• Rework documentation

My understanding is that the API endpoint that is being called is going to be changed/removed in Gitlab. Also, using the module as is, you can fill up the GitLab instance with phantom runners very easily because there is no simple way to verify if a runner is properly registered. I am working on changing the registration and I registration functions to use the runner executable for status information rather than calling the API which will also make it more resilient against any future changes.

[baurmatt]

@yakatz Thanks for your answer! It's unclear to me what you mean, but I'm looking forward to review the PR and get a better understanding of your implementation! :)

[dmaphy]

Is there anything todo to get it working? I was able to use the new workflow without module adjustments. I think the only thing that needs to change is:

• Remove deprecated parameters and (un)registration functions
• Rework documentation

Interesting what you've done there as I didn't manage to do this until now. As the new registration process seems to always require that you create the runner via the web interface - at least in the first step, to generate the token (compare with https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/runner_tokens/). I've removed the redundant fields name and description and instantly received a Error: Failed to apply catalog: Gitlab runner failed to register: Internal Server Error.

At least removing the tag-list according to the following error message worked without any issues so far (the tag list has to be defined in the web interface when creating the runner now):

FATAL: Runner configuration other than name and executor configuration is reserved (specifically --locked, --access-level, --run-untagged, --maximum-timeout, --paused, --tag-list, and --maintenance-note) and cannot be specified when registering with a runner authentication token. This configuration is specified on the GitLab server. Please try again without specifying any of those arguments. For more information, see https://docs.gitlab.com/ee/ci/runners/new_creation_workflow.html#changes-to-the-gitlab-runner-register-command-syntax 

Looking forward to support you here where I can!

[yakatz]

Sorry, my dissertation is taking more time than I thought and I was also out sick for a few days. I will hopefully get this out in the next few days.

[baurmatt]

@dmaphy Are you using registration-token or token?

I've manually created a token in the UI and configured the token parameter while removing other deprecated/obsolete parameters registration-token, description, tag-list, run-untagged, ...

[dmaphy]

I think my problem previously was, that I removed also the name, but removing the description would have been enough. Removing everything deprecated and renaming registration-token to token did the job! Thanks!

[yakatz]

That technically works, but you run the risk of filling up the Gitlab instance with phantom runners since it creates a new runner entry every time the registration token is used.

[dmaphy]

As I understand this [1] the runner has to be created via Gitlab UI. So no, I wasn't able to create more than one instance at the same time. Even with running the puppet run ten times or more.

[1] https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/runner_tokens/#comparison-of-current-and-new-runner-registration-flow

[baurmatt]

That technically works, but you run the risk of filling up the Gitlab instance with phantom runners since it creates a new runner entry every time the registration token is used.

I think that's only true for the old registration-token process, that's why I've implemented the gitlab_ci_runner::(un)register functions back in the days :)

[juokelis]

I am trying to solve the issue in #198 but I am failing the tests. I assume that automated tests should be reimagined now with a new flow. The module looks like working through. At least foe me :) Please help me with the tests and let's get a new flow solution live at last.

[aleksejkov]

Do we have any new info regarding this issue?

[yakatz]

Sorry I haven't gotten back to this yet. Hopefully in the next few days.