Automating Global Registration (with Ansible)

Thanks to @lstejska we will soon have an Ansible module to generate Global Registration commands, so that users can utilize GR from Ansible.

During our last triage session, @wbclark @x9c4 and myself talked a lot about this, and how we can make GR more native to Ansible (and other automation frameworks).

To understand what we mean by that, let’s first look at the current API.

To get a registration command, you POST to /api/registration_commands and provide some details how the registration should happen, and get a JSON with a single entry back:

{"registration_command":"curl -sS  ''http://localhost:3000/register?location_id=3\u0026organization_id=4''
        -H ''Authorization: Bearer some_token''
        | bash"}

This is the literal command people should copy&paste from the UI to the shell of the to-be-registered machine and it works perfectly in this case.

Now, switching the focus from people to machines, things get a bit different.

Ansible has a shell module and we could essentially do shell: "{{ registration_command }}" to get the system registered.
However, it feels weird to use curl | bash if you could use the get_url to fetch the script, and then call shell (or command) to execute it. (This also accidentally makes debugging easier, as curl | bash wrapped inside Ansible is really hard to follow if something goes wrong).
Another possibility would be to return the already rendered script, and let Ansible do the distribution by whatever means it thinks.

The first half can probably be trivially implemented by extending the response to look like:

{
  "registration_command":"curl … | bash",
  "registration_url": "http://localhost:3000/…",
  "registration_token": "some_token"
}

Would such an extension make sense? Or do we oversee something?

5 Likes

We can skip the generating of registration command and call get_url: /register endpoint right away, then save the output to variable for example registration_template & do shell: "{{ registration_template }}".

However this approach have one con, we will loose all the validations that are done while generating the registration command, like missing activation key, not existing organization and so on.

The first half can probably be trivially implemented by extending the response

This would be easy to do. registration_command is unchanged so hammer and other tools will still works, plus we don’t have to care about backward compatibility.
registration_url would be useful for Ansible modules and registration_token is not needed as Ansible will use admin:password authentication.