CaC for Automation Hub

Intellectually, we would like to start with the configuration of the controller, however, the configuration of the controller has a number of dependencies on the automation hub, which make it necessary to perform the configuration of the automation hub before that of the controller. We also don't want to have to click this together by hand, but that it is fully automatic after the start signal.

In-house developed collections and Execution environments are not part of this part of the configuration, this is for a specific reason, which we will explain later.

This chapter will deal with the following:
- The pipeline code
- The playbook used in the pipeline
- Git repository documentation
- Documentation of the parameters
- Keep collections in sync with redhat

It's not difficult to manage and implement CaC, but you have to be very meticulous with what you put in the files. If something is wrong in the yaml syntax, your pipeline will fail before anything is changed. If it is correct syntax-wise, it will be set. One option may be to take a snapshot of your ansible automation platform via the virtualization platform for major updates before pushing the update in git. If things go wrong, you can restore the snapshot.

CaC pipeline

The pipeline is very similar to the pipeline for the controller. This version is an earlier version, where the order of the environments was not enforced. Choose a version that you feel most comfortable with.

The pipeline for the automation hub uses a few other variables, making it suitable for automation hub.

The pipeline code for gitlab:

# Pull the ansible config as code image
image: localhost:5000/ansible-image:1.0
# List of pipeline stages
stages:
  - lint
  - Configure automation hub
lint:
  tags:
    - shared
  stage: lint
  rules:
    - if: '$CI_COMMIT_REF_NAME != "dev"
           && $CI_COMMIT_REF_NAME != "test"
           && $CI_COMMIT_REF_NAME != "accp"
           && $CI_COMMIT_REF_NAME != "prod"'
  script:
    - echo "From pipeline - Start linting on '$CI_COMMIT_REF_NAME'"
    - ansible-lint

configure_from_merge:
  tags:
    - shared
  stage: Configure automation hub
rules:
    - if: '$CI_COMMIT_BRANCH == "dev"
           && $CI_PIPELINE_SOURCE == "push"
           && $CI_COMMIT_MESSAGE =~ /Merge branch/i'
    - if: '$CI_COMMIT_BRANCH == "test"
           && $CI_PIPELINE_SOURCE == "push"
           && $CI_COMMIT_MESSAGE =~ /Merge branch/i'
    - if: '$CI_COMMIT_BRANCH == "accp"
           && $CI_PIPELINE_SOURCE == "push"
           && $CI_COMMIT_MESSAGE =~ /Merge branch/i'
    - if: '$CI_COMMIT_BRANCH == "prod"
           && $CI_PIPELINE_SOURCE == "push"
           && $CI_COMMIT_MESSAGE =~ /Merge branch/i'
  script:
    - echo "From pipeline - Start automation configuration on '$CI_COMMIT_BRANCH'
Environment"
    - ansible-playbook main.yml
      -i inventory.yaml
      -e instance=hub_$CI_COMMIT_BRANCH
      -e branch_name=$CI_COMMIT_BRANCH
      --vault-password-file <(echo ${VAULT_PASSWORD})
configure_from_trigger:
  tags:
    - shared
  stage: Configure automation hub
  rules:
    - if: '$CI_PIPELINE_SOURCE == "pipeline"'
  script:
    - echo "Pipeline triggered by '$CI_PIPELINE_SOURCE' ref"
    - echo "From pipeline - Start automation hub recovery on '$CI_COMMIT_REF_NAME'
Environment"
    - ansible-playbook main.yml
      -i inventory.yaml
      -e instance=controller_$CI_COMMIT_REF_NAME
      -e branch_name=$CI_COMMIT_REF_NAME
      --vault-password-file <(echo ${VAULT_PASSWORD})

The above code is triggered in 3 possible scenarios and will execute the code under "script" for the scenario in question. Each scenario has a number of conditions that must be met in order to execute that part of the pipeline. Here you can see that an ansible playbook is being run to perform the configuration.

There are a number of variables used in the call of the playbook, these do not come out of the blue, but this is where they come from:

Variable Description
$CI_COMMIT_REF_NAME $CI_COMMIT_BRANCH This is an internal variable that is given to each pipeline task by gitlab, the content of this variable is the branch for which the pipeline was started. By using these, we can magically tell the playbook what environment to configure.
$VAULT_PASSWORD Of course, this is not a standard variable of gitlab, we define this variable in gitlab with the project in the "Settings \ CI/CD \ Variables", where we make sure that it has "Masked and Expanded" as settings. This is where we store the vault password, with which the passwords or files are encrypted in ansible.

The Playbook:

---
# https://github.com/ansible/galaxy_collection/tree/devel/roles

- hosts: "{{ instance }}"
  connection: local

  pre_tasks:
    - name: Set the automation hub vars
      ansible.builtin.set_fact:
        ee_image_push: true
        ee_validate_certs: false
        ee_create_ansible_config: false
        ah_auto_approve: true
        ah_collection_repositories: |
          {{ ah_collection_repositories_all |
          community.general.lists_mergeby( vars['ah_collection_repositories_' +
branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_collection_remotes: |
          {{ ah_collection_remotes_all |
          community.general.lists_mergeby( vars['ah_collection_remotes_' +
branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_collections: |
          {{ ah_collections_all |
          community.general.lists_mergeby( vars['ah_collections_' + branch_name],
          'collection_name', recursive=true, list_merge='append' ) }}
        ah_ee_images: |
          {{ ah_ee_images_all |
          community.general.lists_mergeby( vars['ah_ee_images_' + branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_ee_namespaces: |
          {{ ah_ee_namespaces_all |
          community.general.lists_mergeby( vars['ah_ee_namespaces_' + branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_ee_registries: |
          {{ ah_ee_registries_all |
          community.general.lists_mergeby( vars['ah_ee_registries_' + branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_ee_repositories: |
          {{ ah_ee_repositories_all |
          community.general.lists_mergeby( vars['ah_ee_repositories_' +
branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_groups: |
          {{ ah_groups_all |
          community.general.lists_mergeby( vars['ah_groups_' + branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_group_roles: |
          {{ ah_group_roles_all |
          community.general.lists_mergeby( vars['ah_group_roles_' + branch_name],
          'groups', recursive=true, list_merge='append' ) }}
        ah_namespaces: |
          {{ ah_namespaces_all |
          community.general.lists_mergeby( vars['ah_namespaces_' + branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_roles: |
          {{ ah_roles_all |
          community.general.lists_mergeby( vars['ah_roles_' + branch_name],
          'name', recursive=true, list_merge='append' ) }}
        ah_users: |
          {{ ah_users_all |
          community.general.lists_mergeby( vars['ah_users_' + branch_name],
          'username', recursive=true, list_merge='append' ) }}

  roles:
    - infra.ah_configuration.dispatch

You can see in the playbook above, that very little actually happens, other than putting together some list variables (as explained in the previous chapter). Then we kick off the configuration role and wait for everything to be configured. The prerequisite for this to work is that the infra.ah_configuration collection is installed.

We've worked a bit of magic here to avoid duplication of data and to make the whole thing a little simpler and less error-prone. The trick here is to merge the lists, if you read the documentation of the configuration as code, you either create a set of files for each environment, where you also have to make each change 4x. Or you can create a set of files that is applied everywhere and does not allow variation in the environments.

We have chosen a solution that allows both:
- Definitions for all environments
- Differences by environment

By recording these in a kind of inventory structure and merging the variables in the playbook and feeding them to the collection.

CaC GIT repository

The GIT repository for the Automation Hub Configuration As Code, will show the following file and directory structure:

.
├── group_vars
│   ├── all
│   │   ├── ah_collection_remotes.yml
│   │   ├── ah_collection_repositories.yml
│   │   ├── ah_collections.yml
│   │   ├── ah_ee_images.yml
│   │   ├── ah_ee_namespaces.yml
│   │   ├── ah_ee_registries.yml
│   │   ├── ah_ee_repositories.yml
│   │   ├── ah_group_roles.yml
│   │   ├── ah_groups.yml
│   │   ├── ah_namespaces.yml
│   │   ├── ah_roles.yml
│   │   └── ah_users.yml
│   ├─ dev
│   │   ├── ah_collection_remotes.yml
│   │   ├── ah_collection_repositories.yml
│   │   ├── ah_collections.yml
│   │   ├── ah_ee_images.yml
│   │   ├── ah_ee_namespaces.yml
│   │   ├── ah_ee_registries.yml
│   │   ├── ah_ee_repositories.yml
│   │   ├── ah_group_roles.yml
│   │   ├── ah_groups.yml
│   │   ├── ah_namespaces.yml
│   │   ├── ah_roles.yml
│   │   └── ah_users.yml
│   └── test
│       ├── ah_collection_remotes.yml
│       ├── ah_collection_repositories.yml
│       ├── ah_collections.yml
│       ├── ah_ee_images.yml
│       ├── ah_ee_namespaces.yml
│       ├── ah_ee_registries.yml
│       ├── ah_ee_repositories.yml
│       ├── ah_group_roles.yml
│       ├── ah_groups.yml
│       ├── ah_namespaces.yml
│       ├── ah_roles.yml
│       └── ah_users.yml
├── host_vars
│   ├── hub_dev
│   │   └── hub_auth.yaml
│   └── hub_test
│       └── hub_auth.yaml
├── inventory.yaml
├── main.yml
└── README.md

As you can see above, the group_vars directory is built up like an inventory. Essentially, it is, but we're playing some tricks with it in the playbook, because it's not a real inventory for ansible. In addition to the "all" folder, we have created a new folder for each environment in the Enterprise, with all the files in it. The content of the files is definitely different, that's the basis of the magic we unleash on them.

In this environment there is only one dev and test environment, which also means that the git repository also has only 2 branches:
- dev
- test

To avoid errors, all files must be in all folders.

The Magic:

If you look in the files, for example the ah_users.yaml, you may notice a small difference. Below we show the contents of 3 files with the same name that are in different folders: From the group_vars/all folder:

---
ah_users_all:
  - username: test_user
    first_name: user
    last_name: one
    email: user1@example.com
    groups:
      - test_group2
      - test_group4
    append: true
    is_superuser: false
    password: Test123123
    state: present
...

From the group_vars/dev folder:

---
ah_users_dev:
  - username: test_user_dev
    first_name: user
    last_name: two
    email: user2@example.com
    groups:
      - dev_group2
      - dev_group4
    append: true
    is_superuser: false
    password: Test123123
    state: present
...

From the group_vars/test folder:

---
ah_users_test: []
...

If you look closely, not only are the details of the user different, but also the name on the 2nd line of each file is different. As a result, we have to deal with different list of variables per environment and one called "all". By merging this "all" list in the playbook with the specific ones for that environment (e.g. dev) you can keep them the same in all environments by default by adding them in the "all" variable. And implement deviations per environment by adding this environment-specific list variable (e.g. 'ah_users_dev' vs. 'ah_users_all'). If there are no anomalies in the environment (such as "test" in this case), then the variable must be specified as an empty list (ending with "[]" as the example). This method prevents us from copying the same data between environments. If it has to be available in all environments, put it in the "all" variant of the variable, if it is different per environment, then put it is the environment where it deviates. Note: We also used this principle for the controller and event driven controller.

Necessary Variables for CaC

The playbook that will load the configuration into the automation hub must have access to your automation hub, for this the following variables must be populated in the file: host_vars/hub_{env}/hub_auth.yaml This file has the following contents:

---
ah_host: '{ url to your automation hub }'
ah_validate_certs: false
ah_username: '{ admin username }'
ah_password: '{ your vaulted password }'
cloud_token: '{ your vaulted Redhat token }'

These files should never be stored in git without encryption, so there are 2 options: - Encrypt the entire file with a vault password (not recommended, gives issues with linting) - Encrypt user information with Vault In the same folder we create another file: host_vars/hub_{env}/hub_{env}.yaml This includes the following values:

---
hostname: localhost
ah_configuration_async_dir: /opt/app-root/src/.ansible_async/

By means of variables, the operation of the infra.ah_configuration collection can be adjusted, put these variables in this file.

A variable has already been entered, which we needed in the lab to tell ansible where it could find the result files with the logs of the task performed. Be sure to copy this if an error message occurs in your pipeline, you may have to dig through the log to get the location where it is located.

These files must be created for each environment.

The Files

The following describes the contents of all the files that are part of the configuration as code for Automation Hub. An example of a file is shown and a table describing the possible values of the parameters in the file. This documentation can also be found on github, under the code of the redhat_cop.ah_configuration collection. As development is still ongoing, the content in this book will be outdated at some point, so for the latest state of affairs, always check the online documentation for the latest changes. The contents of all these files consist of a list of dictionaries, each dictionary describes a configuration item.

INDEX

ah_collections
ah_collection_repositories
ah_collection_remotes
ah_ee_images
ah_ee_registries
ah_ee_repositories
ah_groups
ah_namespaces
ah_roles
ah_users

The information below is taken from the collection documentation on github: infra.ah_configuration

ah_collections

Here are the options for the variable ah_collections, an example is given below. This allows you to import your own collections from a local file system or from a git repository into the hub.

Important Although this is supported, the fact remains that the (tar) files for those collections must already be present on the system. It might be more convenient to provide the collection repository with a pipeline, so that it takes care of it itself, without the intervention of more configuration code. See Chapter Collections for more information.

Yaml Example

---
ah_collections_all:
  - namespace: 'awx'
    name: 'awx'
    path: /var/tmp/collections/awx_awx-15.0.0.tar.gz
    state: present

  - namespace: test_collection
    name: test
    version: 4.1.2
    state: absent

Data Structure

ah_collections Variables

Variable Name Default Value Required Description Example
namespace "" yes Namespace name. Must be lower case containing only alphanumeric characters and underscores.
"awx" name "" yes Collection name. Must be lower case containing only alphanumeric characters and underscores.
version "" no Collection Version. Must be lower case containing only alphanumeric characters and underscores. If not provided and 'auto_approve' true, will be derived from the path.
path "" no Collection artifact file path.
wait "true" no Waits for the collection to be uploaded
auto_approve "true" no Approves a collection and requires version to be set.
timeout "true" Maximum time to wait for the collection approval
interval "true" 10 Interval at which approval is checked
overwrite_existing "false" no Overwrites an existing collection and requires version to be set.
state "present" no Desired state of the resource

To publish a collection from a GIT repository in automation hub, use the following structure: Yaml Example

---
ah_collections_all:
  - collection_name: cisco.iosxr
    git_url: https://github.com/ansible-collections/cisco.iosxr
    key_path: /home/user/.ssh/keyfile

ah_auto_approve: true
Variable Name Default Value Required Type Description
collection_name "" yes str Name of collection, normally the last part before the / in a git url.
git_url "" no str Url to git repo. Required if collection_local_path not set
version "" no str Git ref to pull. Will default to default branch if unset. Can specify tag, branch or commit ref here.
key_path "" no str Path to ssh key for authentication.
ssh_opts "" no str Options git will pass to ssh when used as protocol.
collection_local_path "" no str Path to collection stored locally. Required if git_url not set. This value will be used rather than git_url if set.

Back to index

ah_collection_repositories

In this file, the remote repositories are defined, usually these will be the community and the rh-certified remote repositories.

Yaml Example

---
ah_collection_repositories_all:
  - Name: ""
    description: "description of foobar repository"
    pulp_labels:
      pipeline: "approved"
    distribution:
      Name: ""
      state: present
    remote: community

Data structure

Collection Repository Variables

Variable Name Default Value Required Type Description
name "" yes str Collection Repository name. Probably one of community, validated, rh-certified, or one you have created.
description "" no str Description to use for the Collection Repository.
retain_repo_versions 0 no Int Retain X versions of the Collection repository. Default is 0 which retains all versions.
pulp_labels "" no dict Pipeline and search options for the collection repository. See additional options below for detals.
distribution "" no dict Distribution options for the collection repository. See additional options below for details. Most users will leave this blank
private "" no boolean Make the Collection repository private.
remote "" no str Remote repository name. This is used if the collections use a remote source.
update_repo false no bool Wait for the Collection repository to finish syncing before returning.
wait true no bool Wait for the Collection repository to finish syncing before returning.
interval 1.0 no float The interval to request an update from Automation Hub.
timeout "" no Int If waiting for the project to update this will abort after this amount of seconds.
state present no str Desired state of the collection repository. Either present or absent.

Additional Options Variables

---
pulp_labels:
  pipeline: "approved"
  hide_from_search: ""
distribution:
  Name: ""
  state: present
Variable Name Default Value Required Type Description
pipeline "" no str Description to use for the Collection Repository.
hide_from_search "" no str Pipeline and search options for the collection repository.
name "" no dict Distribution name to use for this collection repository. Will default to repository name if not provided.
state absent no str Desired state of the distribution. Either present or absent.

Back to index

ah_collection_remotes

By means of this file, you add the configuration to synchronize the collections with the remote sources of redhat. So far, only the rh-certified and the community are present there.

Yaml Example

---
ah_collection_remotes_all:
  - name: community-infra
    url: https://beta-galaxy.ansible.com/
    requirements:
      - name: infra.ee_utilities
      - name: infra.controller_configuration

Data Structure

Variable Name Default Value Required Description Example
name `` yes Repository name. Probably one of community, validated, or rh-certified
url https://cloud.redhat.com/api/automation-hub/ no (ah_repository_certified) Remote URL for the repository. https://console.redhat.com/api/automation-hub/content/
url https://galaxy.ansible.com/api/ no (ah_repository_community) Remote URL for the repository.
auth_url https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token no (ah_repository_certified) Remote URL for the repository authentication if separate.
token `` no Token to authenticate to the remote repository.
policy immediate no The policy to use when downloading content. Can be one of immediate, When syncing, download all metadata and content now..
requirements `` no Requirements, a list of collections in requirements file format to limit thedownload from remote. This will only download provided ollections. This is only the list under collections. See examples for usuage.
requirements_file `` no A yaml requirements file to download from remote. In requirements file format. Exclusive with requirements
username `` no Username to authenticate to the remote repository.
password `` no Password to authenticate to the remote repository.
tls_validation true no Whether to use TLS validation against the remote repository true
client_key `` no A PEM encoded private key file used for authentication
client_cert `` no A PEM encoded client certificate used for authentication
ca_cert `` no A PEM encoded CA certificate used for authentication
client_key_path `` no Path to a PEM encoded private key file used for authentication
client_cert_path `` no Path to a PEM encoded client certificate used for authentication
ca_cert_path `` no Path to a PEM encoded CA certificate used for authentication
download_concurrency 10 no Number of concurrent collections to download.
max_retries 0 no Retries to use when unning sync. Default is 0 which does not limit.
rate_limit 8 no Limits total download rate in requests per second.
signed_only false no Only download signed collections false
sync_dependencies false no Whether to download depenencies when syncing collections. false
proxy_url `` no The URL for the proxy. Defaults to global proxy_url variable.
proxy_username `` no The username for the proxy authentication. Defaults to global proxy_username variable.
proxy_password `` no The password for the proxy authentication. Defaults to global proxy_password variable.
state present no Desired state of the collection_remote. Either present or absent.

ah_ee_images

Add the execution environment images in this file to load them into the automation hub. Yaml Example

---
ah_ee_images_all:
  - name: ansible-automation-platform-20-early-access/ee-supported-rhel8:2.0.0-15
    state: present
    append: false
    tags:
      - v2
      - "2.0"
      - prod1

Data Structure

Variable Name Default Value Required Type Description
name "" yes str Execution environment image name. Must be lower case containing only alphanumeric characters and underscores.
append true no bool Whether to append or replace the tags specified to the image.
tags "" no str List of the image tags to update.
state present no str Desired state of the ee_image. (Possible values of present or absent)

Back

ah_ee_registries

Create EE registries in automation hub.

Yaml Example

---
ah_ee_registries:
  - name: myreg
    url: https://quay.io/my/registry 

Data Structure
EE Registry Variables

Variable Name Default Value Required Type Description
name "" yes str Registry name. Must be lower case containing only alphanumeric characters and underscores.
new_name "" "no" str Setting this option will change the existing name (looked up via the name field.
url "" yes str The URL for the registry
username "" no str The username for authentication to the registry
password "" no str The password for authentication to the registry
tls_validation "" no str Whether to use TLS when connecting to the registry
download_concurrency "" no str Number of concurrent collections to download
rate_limit "" no str Limits total download rate in requests per second.
state present no str Desired state of the ee_registry.

Index EE Registries in Automation Hub. Add the following parameters to ah_ee_registries to ensure that it is indexed.

Data Structure

EE Registry Variables

Variable Name Default Value Required Type Description
name "" yes str Registry name. Must be lower case containing only alphanumeric characters and underscores.
index false no bool Whether to index the ee_registry. By default it will not index unless this is set to true.
wait true no str Whether to wait for the indexing to complete
interval ah_configuration_ee_registry_index_async_delay no str The interval which the indexing task will be checked for completion
timeout "" no str How long to wait for the indexing task to complete

Synchronize EE Registries in Automation Hub.
Add the following variables to ah_ee_registries, to synchronize the registry.

Data Structure

Registry Variable

Variable Name Default Value Required Type Description
name "" yes str Registry name. Must be lower case containing only alphanumeric characters and underscores.
sync false no bool Whether to sync the ee_registry. By default it will not sync unless this is set to true.
wait true no str Whether to wait for the sync to complete
interval ah_configuration_ee_registry_sync_async_delay no str The interval which the sync task will be checked for completion
timeout "" no str How long to wait for the sync task to complete

Back

ah_ee_repositories

Create EE repositories in Automation Hub.
Yaml Example

---
ah_ee_repositories_all:
  - name: abc15
    description: string
    readme: "# My ee repo"

Data Structure

Repository Variables

Variable Name Default Value Required Type Description
name "" yes str Repository name. Must be lower case containing only alphanumeric characters and underscores.
description "" yes str Description to use for the Repository.
readme "" no str The readme for the ee repository. (mutex with readme_file)
readme_file "" no str The file location for the readme for the ee repository. (mutex with readme)
state present no str Desired state of the ee_repository.
registry "" no str The remote registry that the repository belongs in.
upstream_name "" no str The name of the image upstream.
include_tags "" no str The tags to pull in.
xclude_tags "" no str The tags to avoid pulling in.

Synchronize EE Repositories in Automation Hub.Add the following variables ah_ee_repositories, to synchronize.

Data Structure

Repository Variabelen

Variable Name Default Value Required Type Description
name "" yes str Repository name. Must be lower case containing only alphanumeric characters and underscores.
sync false no bool Whether to sync the ee_registry. By default it will not sync unless this is set to true.
wait true no str Whether to wait for the sync to complete
interval ah_configuration_ee_repository_sync_async_delay no str The interval which the sync task will be checked for completion
timeout "" no str How long to wait for the sync task to complete

Back

ah_groups

Creation of user groups in Automation Hub.

Yaml Example

---
ah_groups_all:
  - name: group1
    state: present

Data Structure

Group Variables

Variable Name Default Value Required Type Description
name "" yes str Group Name. Must be lower case containing only alphanumeric characters and underscores.
perms "" yes str The list of permissions to add to or remove from the given group. See below for options.
state present no str Desired state of the group.

Assigning roles to ah_groups

Add the following variables to ah_groups to associate roles with groups. The structure looks like this:

- roles:
    - container.containerdistribution_owner
  targets:
    execution_environments:
      - ee-minimal-rhel8

Data Structure

The Group Variable

Variable Name Default Value Required Type Description
groups "" yes str List of Group Names to apply the roles to. If the group does not exist, it will be created. Must be lower case containing only alphanumeric characters and underscores.
role_list "" yes str The list of roles to add to or remove from the given group. See below for options.
state present no str Desired state of the group. Can be present, enforced, or absent. If absent, then the module deletes the given combination of roles for given groups. If present, then the module creates the group roles if it does not already exist. If enforced, then the module will remove any group role combinations not provided.

role_list The role_list variable is a combination of roles and targets that are applied to the groups mentioned in groups. The roles mentioned can consist of roles created with the role role, roles created with the ah_role or the standard built-in roles. If no targets are specified, the roles are assigned globally to the groups. The targets consist of the following:

Target Description
collection_namespaces List of collection namespaces to apply the roles to.
collection_remotes List of collection remotes to apply the roles to.
collection_repositories List of collection repositories to apply the roles to.
execution_environments List of execution environments to apply the roles to.
container_registery_remotes List of container registery remotes to apply the roles to.

Yaml Example

---
ah_group_roles:
  - state: present
    groups:
      - santa
      - group1
    role_list:
      - roles:
          - container.containerdistribution_owner
        targets:
          execution_environments:
            - redhat_cop/config_as_code_ee
      - roles:
          - galaxy.container_remote
        targets:
          container_registery_remotes:
            - quay
      - roles:
          - galaxy.user_admin
          - galaxy.group_admin
      - roles:
          - galaxy.ansible_repository_owner
        targets:
          collection_repositories:
            - validated
      - roles:
          - galaxy.collection_namespace_owner
        targets:
          collection_namespaces:
            - autohubtest2

Back

ah_namespaces

Create Namespaces in Automation Hub.
Yaml Example

---
ah_namespaces_all:
  - name: abc15
    company: Redhat
    email: user@example.com
    avatar_url: https://static.redhat.com/libs/redhat/brand-
assets/latest/corp/logo.svg
    description: string
    resources: "# Redhat\nA Namespace test with changes"
    links:
      - name: "New_Google"
        url: "http://www.google.com"
    groups:
      - name: system:partner-engineers
        object_roles:
          - "change_namespace"
          - "upload_to_namespace"

Data Structure

Namespace Variables

Variable Name Default Value Required Type Description
name "" yes str Namespace name. Must be lower case containing only alphanumeric characters and underscores.
new_name "" yes str Setting this option will change the existing name (looked up via the name field).
description "" yes str Description to use for the Namespace.
company "" no str Namespace owner company name.
email "password" yes str Namespace contact email.
avatar_url "public" yes str Namespace logo URL.
resources "" no str Namespace resource page in Markdown format.
links [] no list A list of dictionaries of Name and url values for links related the Namespace. See below for details.
groups [] yes list A list of dictionaries of the Names of groups that own the Namespace.
state present no str Desired state of the namespace.

Links |Variable Name|Default Value|Required|Type|Description| |---|---|---|---|---| |name|""|yes|str|Link Text.| |description|""|yes|str|URL link.|

Back

ah_roles

Create roles with permissions in AutomationHub.

Yaml Example

---
ah_roles_all:
  - name: galaxy.stuff.mcstuffins
    description: test
    perms:
      - add_user
      - change_user
      - delete_user
      - view_user

Data Structure

Role Variables

Variable Name Default Value Required Type Description
name "" yes str Group Name. Must be lower case containing only alphanumeric characters and underscores. Must start with 'galaxy.'.
description "" yes str The description of the permision role.
perms "" yes str The list of permissions for the given role. See below for options.
state present no str Desired state of the group.

perms The module accepts the following roles:
- For user management: add_user, change_user, delete_user, and view_user.
- For group management:add_group, change_group, delete_group, and view_group.
- For collection namespace management:add_namespace, change_namespace, upload_to_namespace, and delete_namespace.
- For collection content management:modify_ansible_repo_content, delete_collection and sign_ansiblerepository.
- For remote repository configuration:change_collectionremote, view_collectionremote, add_collectionremote, delete_collectionremote, and manage_roles_collectionremote.
- For Ansible Repository management:only with private automation hub v4.7.0 add_ansiblerepository, change_ansiblerepository, delete_ansiblerepository, manage_roles_ansiblerepository, repair_ansiblerepository, view_ansiblerepository.
- For container image management:only with private automation hub v4.3.2 or later, change_containernamespace_perms, change_container, change_image_tag, create_container, Push existing container push_container, namespace_add_containerdistribution, manage_roles_containernamespace, and delete_containerrepository.
- For remote registry management: add_containerregistryremote, change_containerregistryremote, anddelete_containerregistryremote.
- For task management:change_task, view_task, and delete_task.
- It is also possible to add or remove everything at once with * or all.

Back

ah_users

Create users in Automation Hub. Note, create at least 1 extra superuser via the "all/ah_users.yaml" and use this user to upload collections via the pipeline, if you use the same user everywhere, your token will become invalid and you will have to create new tokens everywhere all the time. The advice is therefore to create new users for the following actions and possibly generate tokens, so that they remain usable:
- Collection uploads
- EE uploads
- AAP sync token

Yaml Example

---
ah_users_all:
  - username: user1
    groups:
      - group1
    append: true
    first_name: user
    last_name: one
    email: user1@example.com
    is_superuser: false
    password: p4ssword
    state: present

Data Structure

User Variables

Variable Name Default Value Required Type Description
username "" yes str Username. Must be lower case containing only alphanumeric characters and underscores.
groups [] no list List of the groups to update.
append true no str Whether to append or replace the group list provided.
first_name "" no str User's first name.
last_name "" no str User's last name.
email "" no str User's email address.
is_superuser false no bool Whether the user is a superuser.
password "" no bool User's password as a clear string. The password must contain at least 9 characters with numbers or special characters.
state present no str Desired state of the user.

Index

Back

Back to Site