Add organization fully automated

25-08-2025 Code update
Pipeline check was failing when the gitlab_group contained subgroups group/subgroup, the gitlab api wants '%2F', this is now automaticly converted, where appropiate.
The code was rather ineffient, running several loops with include_tasks from separate files, these includes are now removed and the tasks are incorporated in the main.yml playbook. This new code is now about 60 secs faster at runtime and uses less resources on the execution controller.
Files removed:
- encrypt.sh
- controller_loop.yml
- secure_group.yml
Revised:
- main.yml

documentation

It is the purpose in life of any automation engineer to be able to put our feet on the desk and say "Look mammy, No hands", as everything is automated.
So if my boss comes in saying we need to create a new team repository in rhaap, we just log in, klick on the appropriate rocket and let the automation do the work for us. In these pages I will describe how to enable this.

As I already described, when adding a team to this rhaap configuration, we need to create a new repository, with all the needed files in there to configure the organizations templates and so on..
We could clone a repository from another team (or a template repository) and start configuring the teams properties. The better way is generating this from code and never touch the repository's content. We still need to give the target team access to the newly created repository in gitlab.

When the repository is created, the team must be able to log in to rhaap, so this needs to be configured too.

We created a playbook to handle it all for the installation that is described in these pages.

This playbook is hosted in a gitlab repository that has the following content:

.
├── env_vars.yml
├── files
│   ├── main.yml.txt
│   └── README.md
├── main.yml
├── get_gitlab_api_token.yml
├── other_vars.yml
├── README.md
└── templates
    ├── aap_auth.yml.j2
    ├── aap_env.yml.j2
    ├── controller_credentials.yml.j2
    ├── controller_hosts.yml.j2
    ├── controller_inventory_sources.yml.j2
    ├── controller_inventory.yml.j2
    ├── controller_labels.yml.j2
    ├── controller_notification_templates.yml.j2
    ├── controller_organizations.yml.j2
    ├── controller_projects.yml.j2
    ├── controller_roles.yml.j2
    ├── controller_schedules.yml.j2
    ├── controller_templates.yml.j2
    ├── controller_workflows.yml.j2
    └── repo_inventory.yaml.j2

As you can see, it has a number of templates (these are the templates used for the new repository), a main.yml and a few support files. The README.md should be clear, these describe the working of the code and will not be listed here.

Here is a table with all files listed and links to the content and descriptions:

Filename	link
env_vars.yml	env_vars.yml
main.yml.txt	main.yml.txt
main.yml	main.yml
get_gitlab_api_token.yml	get_gitlab_api_token.yml
other_vars.yml	other_vars.yml
aap_auth.yml.j2	aap_auth.yml.j2
aap_env.yml.j2	aap_env.yml.j2
controller_credentials.yml.j2	controller_credentials.yml.j2
controller_hosts.yml.j2	controller_hosts.yml.j2
controller_inventory_sources.yml.j2	controller_inventory_sources.yml.j2
controller_inventory.yml.j2	controller_inventory.yml.j2
controller_labels.yml.j2	controller_labels.yml.j2
controller_notification_templates.yml.j2	controller_notification_templates.yml.j2
controller_organizations.yml.j2	controller_organizations.yml.j2
controller_projects.yml.j2	controller_projects.yml.j2
controller_roles.yml.j2	controller_roles.yml.j2
controller_schedules.yml.j2	controller_schedules.yml.j2
controller_templates.yml.j2	controller_templates.yml.j2
controller_workflows.yml.j2	controller_workflows.yml.j2
repo_inventory.yaml.j2	repo_inventory.yaml.j2

If all of the above is copied into a repository, you should be able to create a project in rhaap to run this playbook. First you should configure all variables for your environment into the env_vars.yml and other_vars.yml. With the addition af the right credentials, this play will create a new organization at each run, by providing just 2 survey variables:
- organization_short_name
- team_password

For testing purposes, you might want to set the pipeline variable to a pipeline script that does nothing. This enables you to check the created files for errors.

Back