ara Documentation

Release 1.0.0

Red Hat

Jun 04, 2019

 Contents

1 Table of Contents 3
1.1 FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Installing ARA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Configuring Ansible to use ARA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Configuring the ARA Ansible plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 ARA API server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 ARA API Server authentication and security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.7 API Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.8 Using ARA API clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.9 Setting playbook names and labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.10 Recording arbitrary data in playbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.11 How to contribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.12 ansible-role-ara-api . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.13 ansible-role-ara-web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.14 ansible-role-ara-tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

i
ii
 ara Documentation, Release 1.0.0

Contents 1
ara Documentation, Release 1.0.0

2 Contents
 CHAPTER 1

Table of Contents

1.1 FAQ

1.1.1 What is ARA ?

ARA Records Ansible playbooks and makes them easier to understand and troubleshoot.
ARA is currently composed of three different free and open source projects:
• [Link] for the REST API server and Ansible plugins
• [Link] for the standalone web interface
• [Link] for project-specific infrastructure needs (such as the
[Link] website)

1.1.2 How does it work ?

ARA Records Ansible playbooks through an Ansible callback plugin.

3
ara Documentation, Release 1.0.0

0. ARA is installed and Ansible is configured to use the callback plugin

1. An ansible-playbook command is executed
2. Ansible triggers the callback plugin for every event (v2_playbook_on_start,
v2_runner_on_failed, etc.)
3. The relevant information is retrieved from the Ansible playbook execution context and is sent to the API server
4. The API server validates and serializes the data before storing it the configured database backend
5. The API server sends a response back to the API client with the results
6. The callback plugin returns, ending the callback hook
7. Ansible continues running the playbook until it fails or is completed (back to step 2)
Once the data has been saved in the database, it is made available for query by the API.

1.1.3 What’s an Ansible callback ?

Ansible Callbacks are essentially hooks provided by Ansible. Ansible will send an event and you can react to it with a
callback. You could use a callback to do things like print additional details or, in the case of ARA, record the playbook
run data in a database.

1.1.4 Are there live demos available ?

Yes, you can find persistent and up-to-date live demos at [Link] for the API and
[Link] for the ara-web standalone interface.

1.1.5 What versions of Ansible are supported ?

The upstream Ansible community and maintainers provide support for the latest three major stable releases and ARA
follows the same support cycle.
For example, if the latest version of Ansible is 2.8, then the latest release of ARA will support 2.8 as well as 2.7 and
2.6.

4 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

For more information on Ansible’s release and maintenance cycle, you can refer to the Ansible documentation.
If you are using a release of Ansible that is no longer supported, we strongly encourage you to upgrade as soon as
possible in order to benefit from the latest features and security fixes.
Older unsupported versions of Ansible can contain unfixed security vulnerabilities (CVE).

1.1.6 What versions of Python are supported ?

Before version 1.0 of ARA, both python2 and python3 were supported. Versions of ARA after 1.0 are not designed to
support python2 in consideration that python2 will reach end of life in January 2020.

1.1.7 Why ARA instead of <X> ?

Ansible is an awesome tool. It can be used for a lot of things.

Reading and interpreting the output of an ansible-playbook run, especially one that is either long running,
involves a lot of hosts or prints a lot of output can be hard to understand and troubleshoot.
This is especially true when you happen to be running Ansible hundreds of times during the day, through automated
means – for example when doing continuous integration or continuous delivery.
ARA aims to do one thing and do it well: Record Ansible playbooks and provide you with the tools you need to make
your playbook results intuitive for you and for your systems.
The great thing about ARA is that it is not mutually exclusive with other software and systems you might already be
using Ansible with today.
There is nothing preventing you from using ARA with other tools such as Ansible Tower (or AWX), Zuul, Jenkins or
Rundeck since all you need to get started is to install and enable the ARA Ansible callback plugin.

1.1.8 Can I set up the different components of ARA on different servers ?

Yes.
The defaults are set to have the callback use the offline API client which expects the server dependencies installed and
the data is saved to a local sqlite database.
However, the callback can also be configured to send data to a specified API server address and the API server can be
configured to use a remote database server such as PostgreSQL or MySQL.
The web client interface provided by ara-web is stateless and requires an API server address to connect to. It can be
installed anywhere that has access to the API server.

1.2 Installing ARA

1.2.1 Requirements and dependencies

ARA should work on any Linux distributions as long as python3 is available.

Since ARA provides Ansible plugins to record data, it should be installed wherever Ansible is running from so that
Ansible can use those plugins. The API server does not require to run on the same machine as Ansible.
By default, only the client and plugin dependencies are installed. This lets users record and send data to a remote API
server without requiring that the API server dependencies are installed.

1.2. Installing ARA 5

ara Documentation, Release 1.0.0

If you are standing up an API server or if your use case is about recording data locally or offline, the required depen-
dencies can be installed automatically by suffixing [server] to your pip install commands.

1.2.2 Installing from PyPi or from source

First, it is recommended to use a python virtual environment in order to avoid conflicts with your Linux distribution
python packages.

python3 -m venv ~/.ara/virtualenv

To install the latest pre-release for ARA 1.0 from PyPi:

# With the API server dependencies

~/.ara/virtualenv/bin/pip install --pre ara[server]

# Without the API server dependencies

~/.ara/virtualenv/bin/pip install --pre ara

Installing from source is possible by using the feature/1.0 branch:

# With the API server dependencies

~/.ara/virtualenv/bin/pip install git+[Link]
˓→ara@feature/1.0[server]

# Without the API server dependencies

~/.ara/virtualenv/bin/pip install git+[Link]
˓→ara@feature/1.0

1.2.3 With Ansible roles

Two roles are built-in to help users configure their API and web deployments:
• ansible-role-ara-api to install the python parts (Ansible plugins, API server)
• ansible-role-ara-web to install the web client (nodejs, react+patternfly)

1.3 Configuring Ansible to use ARA

To begin using ARA, you’ll first need to tell Ansible where it is located.
Since this location will be different depending on your operating system and how you are installing ARA, there are
convenient python modules to help you figure out the right paths.
Once you’ve set up the callback_plugins configuration or the ANSIBLE_CALLBACK_PLUGINS environment
variable, Ansible will automatically use the ARA callback plugin to start recording data.
If you’d like to use the ara_record action plugin to record arbitrary data during your playbook, you’ll need to set
action_plugins and ANSIBLE_ACTION_PLUGINS as well.

1.3.1 Using setup helper modules

The modules can be used directly on the command line:

6 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

$ python3 -m [Link]
/usr/lib/python3.7/site-packages/ara

$ python3 -m [Link]
/usr/lib/python3.7/site-packages/ara/plugins

$ python3 -m [Link].action_plugins
/usr/lib/python3.7/site-packages/ara/plugins/action

$ python3 -m [Link].callback_plugins
/usr/lib/python3.7/site-packages/ara/plugins/callback

# Note: This doesn't export anything, it only prints the commands.

# If you want to export directly from the command, you can use:
# source <(python3 -m [Link])
$ python3 -m [Link]
export ANSIBLE_CALLBACK_PLUGINS=/usr/lib/python3.7/site-packages/ara/plugins/callback
export ANSIBLE_ACTION_PLUGINS=/usr/lib/python3.7/site-packages/ara/plugins/action

$ python3 -m [Link]
[defaults]
callback_plugins=/usr/lib/python3.7/site-packages/ara/plugins/callback
action_plugins=/usr/lib/python3.7/site-packages/ara/plugins/action

Or from python, for example:

>>> from [Link] import callback_plugins

>>> print(callback_plugins)
/usr/lib/python3.7/site-packages/ara/plugins/callback

>>> from [Link] import action_plugins

>>> print(action_plugins)
/usr/lib/python3.7/site-packages/ara/plugins/action

1.4 Configuring the ARA Ansible plugins

ARA plugins uses the same mechanism and configuration files as Ansible to retrieve it’s configuration. It comes with
sane defaults that can be customized if need be.
The order of priority is the following:
1. Environment variables
2. ./[Link] (in the current working directory)
3. ~/.[Link] (in the home directory)
4. /etc/ansible/[Link]
When using the [Link] file, the configuration options must be set under the ara namespace, like so:

[ara]
variable = value

1.4. Configuring the ARA Ansible plugins 7

ara Documentation, Release 1.0.0

1.4.1 ARA callback plugin

The ARA callback plugin is the component that recovers data throughout the execution of your playbook and sends it
to the API.
By default, the callback plugin is set up to use the local API server with the offline API client but you can also send
data to a remote API server, specify credentials or customize other parameters:

callback: ara
callback_type: notification
requirements:
- ara
short_description: Sends playbook execution data to the ARA API internally or over
˓→HTTP

description:
- Sends playbook execution data to the ARA API internally or over HTTP
options:
api_client:
description: The client to use for communicating with the API
default: offline
env:
- name: ARA_API_CLIENT
ini:
- section: ara
key: api_client
choices: ['offline', 'http']
api_server:
description: When using the HTTP client, the base URL to the ARA API server
default: [Link]
env:
- name: ARA_API_SERVER
ini:
- section: ara
key: api_server
api_username:
description: If authentication is required, the username to authenticate with
default: null
env:
- name: ARA_API_USERNAME
ini:
- section: ara
key: api_username
api_password:
description: If authentication is required, the password to authenticate with
default: null
env:
- name: ARA_API_PASSWORD
ini:
- section: ara
key: api_password
api_timeout:
description: Timeout, in seconds, before giving up on HTTP requests
default: 30
env:
- name: ARA_API_TIMEOUT
ini:
- section: ara
key: api_timeout
(continues on next page)

8 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

(continued from previous page)

ignored_facts:
description: List of host facts that will not be saved by ARA
type: list
default: ["ansible_env"]
env:
- name: ARA_IGNORED_FACTS
ini:
- section: ara
key: ignored_facts
ignored_arguments:
description: List of Ansible arguments that will not be saved by ARA
type: list
default: ["extra_vars"]
env:
- name: ARA_IGNORED_ARGUMENTS
ini:
- section: ara
key: ignored_arguments

For example, a customized callback plugin configuration might look like this in an [Link] file:

[ara]
api_client = http
api_server = [Link]
api_username = user
api_password = password
api_timeout = 15
ignored_facts = '["ansible_env", "ansible_all_ipv4_addresses"]'
ignored_arguments = '["extra_vars", "vault_password_files"]'

or as environment variables:

export ARA_API_CLIENT=http
export ARA_API_SERVER="[Link]
export ARA_API_USERNAME=user
export ARA_API_PASSWORD=password
export ARA_API_TIMEOUT=15
export ARA_IGNORED_FACTS='["ansible_env", "ansible_all_ipv4_addresses"]'
export ARA_IGNORED_ARGUMENTS='["extra_vars", "vault_password_files"]'

1.4.2 ARA action plugin: ara_record

The ara_record action plugin recovers it’s configuration from the callback plugin.
It is therefore not necessary to configure it explicitely other than enabling Ansible to find it by setting
action_plugins in [Link] or the ANSIBLE_ACTION_PLUGINS environment variable.

1.5 ARA API server configuration

The API server ships with sane defaults, supports the notion of different environments (such as dev, staging, prod) and
allows you to customize the configuration with files, environment variables or a combination of both.
The API is a Django application that leverages django-rest-framework. Both Django and django-rest-framework have
extensive configuration options which are not necessarily exposed or made customizable by ARA for the sake of

1.5. ARA API server configuration 9

ara Documentation, Release 1.0.0

simplicity.

1.5.1 Overview

This is a brief overview of the different configuration options for the API server. For more details, click on the
configuration parameters.

Environment Vari- default Usage

able
ARA_ALLOWED_HOSTS["[Link]", "localhost", Django’s ALLOWED_HOSTS setting
"::1"]
ARA_BASE_DIR ~/.ara/server Default directory for storing data and
configuration
ARA_CORS_ORIGIN_WHITELIST
["[Link] django-cors-headers’s
"[Link] CORS_ORIGIN_WHITELIST
setting
ARA_DATABASE_ENGINE
[Link].sqlite3 Django’s ENGINE database setting
ARA_DATABASE_HOST None Django’s HOST database setting
ARA_DATABASE_NAME~/.ara/server/[Link] Django’s NAME database setting
ARA_DATABASE_PASSWORD
None Django’s PASSWORD database set-
ting
ARA_DATABASE_PORT None Django’s PORT database setting
ARA_DATABASE_USER None Django’s USER database setting
ARA_DEBUG False Django’s DEBUG setting
ARA_ENV default Environment to load configuration for
ARA_LOGGING See ARA_LOGGING Logging configuration
ARA_LOG_LEVEL INFO Log level of the different components
ARA_READ_LOGIN_REQUIRED
False Whether authentication is required for
reading data
ARA_SECRET_KEY Randomized token, see ARA_SECRET_KEY Django’s SECRET_KEY setting
ARA_SETTINGS ~/.ara/server/[Link] Path to an API server configuration file
ARA_WRITE_LOGIN_REQUIRED
False Whether authentication is required for
writing data

1.5.2 Configuration variables

ARA_ALLOWED_HOSTS

• Environment variable: ARA_ALLOWED_HOSTS

• Configuration file variable: ALLOWED_HOSTS
• Type: list
• Provided by: Django’s ALLOWED_HOSTS
• Default: ["[Link]", "localhost", "::1"]
A list of strings representing the host/domain names that this Django site can serve.
If you are planning on hosting an instance of the API server somewhere, you’ll need to add your domain name to this
list.

10 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

ARA_BASE_DIR

• Environment variable: ARA_BASE_DIR

• Configuration file variable: BASE_DIR
• Type: string
• Default: ~/.ara/server
The directory where data will be stored by default.
Changing this location influences the default root directory for the ARA_DATABASE_NAME and ARA_SETTINGS
parameters.
This is also used to determine the location where the default configuration file, [Link], will be generated
by the API server.

ARA_CORS_ORIGIN_WHITELIST

• Environment variable: ARA_CORS_ORIGIN_WHITELIST

• Configuration file variable: CORS_ORIGIN_WHITELIST
• Provided by: django-cors-headers
• Type: list
• Default: ["[Link]:8000", "localhost:3000"]
• Examples:
– export ARA_CORS_ORIGIN_WHITELIST="['[Link]
'[Link]
– In a YAML configuration file:

dev:
CORS_ORIGIN_WHITELIST:
- [Link]
- [Link]
production:
CORS_ORIGIN_WHITELIST:
- [Link]
- [Link]

Hosts in the whitelist for Cross-Origin Resource Sharing.

This setting is typically used in order to allow the API and a web client (such as ara-web) to talk to each other.

ARA_DATABASE_ENGINE

• Environment variable: ARA_DATABASE_ENGINE

• Configuration file variable: DATABASE_ENGINE
• Provided by: Django’s ENGINE database setting
• Type: string
• Default: [Link].sqlite3
• Examples:

1.5. ARA API server configuration 11

ara Documentation, Release 1.0.0

– [Link]
– [Link]
The Django database driver to use.
When using anything other than sqlite3 default driver, make sure to set the other database settings to allow the API
server to connect to the database.

ARA_DATABASE_NAME

• Environment variable: ARA_DATABASE_NAME

• Configuration file variable: DATABASE_NAME
• Provided by: Django’s NAME database setting
• Type: string
• Default: ~/.ara/server/[Link]
The name of the database.
When using sqlite, this is the absolute path to the sqlite database file. When using drivers such as MySQL or Post-
greSQL, it’s the name of the database.

ARA_DATABASE_USER

• Environment variable: ARA_DATABASE_USER

• Configuration file variable: DATABASE_USER
• Provided by: Django’s USER database setting
• Type: string
• Default: None
The username to connect to the database.
Required when using something other than sqlite.

ARA_DATABASE_PASSWORD

• Environment variable: ARA_DATABASE_PASSWORD

• Configuration file variable: DATABASE_PASSWORD
• Provided by: Django’s PASSWORD database setting
• Type: string
• Default: None
The password to connect to the database.
Required when using something other than sqlite.

12 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

ARA_DATABASE_HOST

• Environment variable: ARA_DATABASE_HOST

• Configuration file variable: DATABASE_HOST
• Provided by: Django’s HOST database setting
• Type: string
• Default: None
The host for the database server.
Required when using something other than sqlite.

ARA_DATABASE_PORT

• Environment variable: ARA_DATABASE_PORT

• Configuration file variable: DATABASE_PORT
• Provided by: Django’s PORT database setting
• Type: string
• Default: None
The port to use when connecting to the database server.
It is not required to set the port if you’re using default ports for MySQL or PostgreSQL.

ARA_DEBUG

• Environment variable: ARA_DEBUG

• Configuration file variable: DEBUG
• Provided by: Django’s DEBUG
• Type: string
• Default: false
Whether or not Django’s debug mode should be enabled.
The Django project recommends turning this off for production use.

ARA_ENV

• Environment variable: ARA_ENV

• Configuration file variable: None, this variable defines which section of a configuration file is loaded.
• Type: string
• Default: development
• Provided by: dynaconf
If you are using the API server in different environments and would like keep your configuration in a single file, you
can use this variable to select a specific environment’s settings.
For example:

1.5. ARA API server configuration 13

ara Documentation, Release 1.0.0

# Default settings are used only when not provided in the environments
default:
READ_LOGIN_REQUIRED: false
WRITE_LOGIN_REQUIRED: false
LOG_LEVEL: INFO
DEBUG: false
# Increase verbosity and debugging for the default development environment
development:
LOG_LEVEL: DEBUG
DEBUG: true
SECRET_KEY: dev
# Enable write authentication when using the production environment
production:
WRITE_LOGIN_REQUIRED: true
SECRET_KEY: prod

With the example above, loading the development environment would yield the following settings:
• READ_LOGIN_REQUIRED: false
• WRITE_LOGIN_REQUIRED: false
• LOG_LEVEL: DEBUG
• DEBUG: true
• SECRET_KEY: dev
Another approach to environment-specific configuration is to use ARA_SETTINGS and keep your settings in different
files such as [Link] or [Link] instead.

Tip: If it does not exist, the API server will generate a default configuration file at ~/.ara/server/settings.
yaml. This generated file sets up all the configuration keys in the default environment. This lets users override only
the parameters they are interested in for specific environments.

ARA_LOGGING

• Environment variable: Not recommended, use configuration file

• Configuration file variable: LOGGING
• Type: dictionary
• Default:

LOGGING:
disable_existing_loggers: false
formatters:
normal:
format: '%(asctime)s %(levelname)s %(name)s: %(message)s'
handlers:
console:
class: [Link]
formatter: normal
level: INFO
stream: ext://[Link]
loggers:
(continues on next page)

14 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

(continued from previous page)

ara:
handlers:
- console
level: INFO
propagate: 0
root:
handlers:
- console
level: INFO
version: 1

The python logging configuration for the API server.

ARA_LOG_LEVEL

• Environment variable: ARA_LOG_LEVEL

• Configuration file variable: LOG_LEVEL
• Type: string
• Default: INFO
Log level of the different components from the API server.
ARA_LOG_LEVEL changes the log level of the default logging configuration provided by ARA_LOGGING.

ARA_SETTINGS

• Environment variable: ARA_SETTINGS

• Configuration file variable: None, this variable defines the configuration file itself.
• Type: string
• Default: None
• Provided by: dynaconf
Location of an API server configuration file to load settings from. The API server will generate a default configuration
file at ~/.ara/server/[Link] that you can use to get started.
Note that while the configuration file is in YAML by default, it is possible to have configuration files written in ini,
json and toml as well.
Settings and configuration parsing by the API server is provided by the dynaconf python library.

ARA_READ_LOGIN_REQUIRED

• Environment variable: ARA_READ_LOGIN_REQUIRED

• Configuration file variable: READ_LOGIN_REQUIRED
• Type: bool
• Default: False
• Provided by: django-rest-framework permissions

1.5. ARA API server configuration 15

ara Documentation, Release 1.0.0

Determines if authentication is required before being authorized to query all API endpoints exposed by the server.
There is no concept of granularity: users either have access to query everything or they don’t.
Enabling this feature first requires setting up users.

ARA_SECRET_KEY

• Environment variable: ARA_SECRET_KEY

• Configuration file variable: SECRET_KEY
• Provided by: Django’s SECRET_KEY
• Type: string
• Default: Randomized with [Link].get_random_string()
A secret key for a particular Django installation. This is used to provide cryptographic signing, and should be set to a
unique, unpredictable value.
If it is not set, a random token will be generated and persisted in the default configuration file.

ARA_WRITE_LOGIN_REQUIRED

• Environment variable: ARA_WRITE_LOGIN_REQUIRED

• Configuration file variable: WRITE_LOGIN_REQUIRED
• Type: bool
• Default: False
• Provided by: django-rest-framework permissions
Determines if authentication is required before being authorized to post data to all API endpoints exposed by the
server.
There is no concept of granularity: users either have access to query everything or they don’t.
Enabling this feature first requires setting up users.

1.6 ARA API Server authentication and security

The API server ships with a default configuration that emphasizes simplicity to let users get started quickly.
By default:
• A random SECRET_KEY will be generated once if none are supplied
• No users are created
• API authentication and permissions are not enabled
• ALLOWED_HOSTS and CORS_ORIGIN_WHITELIST are configured for use on localhost
These default settings can be configured according to the requirements of your deployments.

16 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

1.6.1 Setting a custom secret key

By default, the API server randomly generates a token for the ARA_SECRET_KEY setting if none have been supplied
by the user.
This value is persisted in the server configuration file in order to prevent the key from changing on every instanciation
of the server.
The default location for the server configuration file is ~/.ara/server/[Link].
You can provide a custom secret key by supplying the ARA_SECRET_KEY environment variable or by specifying the
SECRET_KEY setting in your server configuration file.

1.6.2 User management

The API server leverages Django’s user management but doesn’t create any user by default.

Note: Creating users does not enable authentication on the API. In order to make authentication required for using
the API, see Enabling authentication for read or write access.

In order to create users, you’ll need to create a superuser account before running the API server:

$ ara-manage createsuperuser --username=joe --email=joe@[Link]

Password:
Password (again):
Superuser created successfully.

Tip: If you ever need to reset the password of a superuser account, this can be done with the “changepassword”
command:

$ ara-manage changepassword joe

Changing password for user 'joe'
Password:
Password (again):
Password changed successfully for user 'joe'

Once the superuser has been created, make sure the API server is started and then login to the Django web adminis-
trative interface using the credentials you just set up.
By default, you can start the API server with ara-manage runserver and access the admin interface at http:/
/[Link]:8000/admin/.
Log in to the admin interface:

1.6. ARA API Server authentication and security 17

ara Documentation, Release 1.0.0

Access the authentication and authorization configuration:

And from here, you can manage existing users or create new ones:

18 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

1.6.3 Enabling authentication for read or write access

Once you have created your users, you can enable authentication against the API for read (ex: GET) and write (ex:
DELETE, POST, PATCH) requests.
This is done with the two following configuration options:
• ARA_READ_LOGIN_REQUIRED for read access
• ARA_WRITE_LOGIN_REQUIRED for write access
These settings are global and are effective for all API endpoints.

1.6.4 Setting up authentication for the Ansible plugins

The callback plugin used to record playbooks as well as the ara_record action plugin will need to authenticate
against the API if authentication is enabled and required.
You can specify the necessary credentials through the ARA_API_USERNAME and ARA_API_PASSWORD environ-
ment variables or through your [Link] file:

[defaults]
# ...

[ara]
api_client = http
api_server = [Link]
api_username = ara
api_password = password

1.6. ARA API Server authentication and security 19

ara Documentation, Release 1.0.0

1.6.5 Using authentication with the API clients

To instanciate an authenticated client with the built-in basic HTTP authentication provided by Django:

from [Link] import get_client

client = get_client(
client="http",
endpoint="[Link]
username="ara",
password="password"
)

If you have a custom authentication that is supported by the python requests library, you can also pass the relevant
auth object directly to the client:

from [Link] import AraHttpClient

from requests_oauthlib import OAuth1
auth = OAuth1(
"YOUR_APP_KEY",
"YOUR_APP_SECRET",
"USER_OAUTH_TOKEN",
"USER_OAUTH_TOKEN_SECRET"
)
client = AraHttpClient(endpoint="[Link] auth=auth)

1.6.6 Managing hosts allowed to serve the API

By default, ARA_ALLOWED_HOSTS authorizes localhost, ::1 and [Link] to serve requests for the API
server.
In order to host an instance of the API server on another domain, the domain must be part of this list or the application
server will deny any requests sent to it.

1.6.7 Managing CORS (cross-origin resource sharing)

The ARA_CORS_ORIGIN_WHITELIST default is designed to allow a local development instance of an ara-web dash-
board to communicate with a local development instance of the API server.
The whitelist must contain the domain names where you plan on hosting instances of ara-web.

1.7 API Documentation

The API documentation is a work in progress.

1.7.1 Built-in API browser interface

ARA ships with a helpful interface to navigate the API directly from your favorite web browser.
For example, if you run ara-manage runserver, this interface would be available at [Link]
1:8000/api/v1/:

20 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

You can navigate the interface and drill down to list views, for example:

1.7. API Documentation 21

ara Documentation, Release 1.0.0

You can also see what a detailed view looks like by querying a specific object id:

22 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

Alternatively, you may also find an up-to-date live demonstration of the API at [Link]
[Link].

1.7.2 Relationship between objects

The relationship between objects in the API should be straightforward with an understanding of how Ansible play-
books are executed.
Generally speaking, the data is organized in the following fashion:

labels
|
Playbook -> Play -> Task -> Result <- Host
| | | |
file file content facts

• Every object is associated to a playbook (except labels which are applied to playbooks)
• In a playbook you have plays

1.7. API Documentation 23

ara Documentation, Release 1.0.0

• In plays you have tasks

• In tasks you have results
• Results have a relationship to their parent task and the host the task ran on
• Files are only associated to a playbook but tasks have a reference to the file they were executed from
• Records (provided by ara_record) are only associated to a playbook
Additional fields may only be available in the detailed views. For example:
• Playbooks arguments with /api/v1/playbooks/<id>
• Hosts facts with /api/v1/hosts/<id>
• Results content with /api/v1/results/<id>
• Files content with /api/v1/files/<id>
ARA ships with two built-in API clients to help you get started. You can learn more about those clients in Using ARA
API clients.

1.8 Using ARA API clients

When installing ARA, you are provided with a REST API server and two API clients out of the box:
• AraOfflineClient can query the API without needing an API server to be running
• AraHttpClient is meant to query a specified API server over http

1.8.1 ARA Offline API client

If your use case doesn’t require a remote or persistent API server, the offline client lets you query the API without
needing to start an API server.
In order to use this client, you would instanciate it like this:

#!/usr/bin/env python3
# Import the client
from [Link] import AraOfflineClient

# Instanciate the offline client

client = AraOfflineClient()

1.8.2 ARA HTTP API client

AraHttpClient works with the same interface, methods and behavior as AraOfflineClient.
You can set your client to communicate with a remote ara-server API by specifying an endpoint parameter:

#!/usr/bin/env python3
# Import the client
from [Link] import AraHttpClient

# Instanciate the HTTP client with an endpoint where an API server is listening
client = AraHttpClient(endpoint="[Link]

24 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

1.8.3 Example API usage

For more details on the API endpoints, see API Documentation.

Otherwise, once you’ve instanciated your client, you’re ready to query the API.
Here’s a code example to help you get started:

#!/usr/bin/env python3
# Import the client
from [Link] import AraHttpClient

# Instanciate the HTTP client with an endpoint where an API server is listening
client = AraHttpClient(endpoint="[Link]

# Get a list of failed playbooks

# /api/v1/playbooks?status=failed
playbooks = [Link]("/api/v1/playbooks", status="failed")

# If there are any results from our query, get more information about the
# failure and print something helpful
template = "{timestamp}: {host} failed '{task}' ({task_file}:{lineno})"
for playbook in playbooks["results"]:
# Get a detailed version of the playbook that provides additional context
detailed_playbook = [Link]("/api/v1/playbooks/%s" % playbook["id"])

# Iterate through the playbook to get the context

# Playbook -> Play -> Task -> Result <- Host
for play in detailed_playbook["plays"]:
for task in play["tasks"]:
for result in task["results"]:
if result["status"] in ["failed", "unreachable"]:
print([Link](
timestamp=result["ended"],
host=result["host"]["name"],
task=task["name"],
task_file=task["file"]["path"],
lineno=task["lineno"]
))

Running this script would then provide an output that looks like the following:

2019-03-20T16:18:41.710765: localhost failed 'smoke-tests : Return false' (tests/

˓→integration/roles/smoke-tests/tasks/[Link])

2019-03-20T16:19:17.332663: localhost failed 'fail' (tests/integration/[Link])

1.9 Setting playbook names and labels

ARA provides the ability for users to specify playbook names and labels in order to better distinguish playbooks run
in different environments or purposes.
Names and labels are also searchable by the ARA API, allowing you to find playbooks matching your query.
Names and labels are set as regular Ansible variables:
• ara_playbook_name
• ara_playbook_labels

1.9. Setting playbook names and labels 25

ara Documentation, Release 1.0.0

These variables can be provided by your Ansible inventory, directly in your playbook file, as extra-vars or any other
way supported by Ansible.
For example, in an inventory:

[dev]
host1
host2

[dev:vars]
ara_playbook_name=deploy-dev
ara_playbook_labels='["deploy", "dev"]'

In a playbook:

- name: Deploy dev environment

hosts: dev
vars:
ara_playbook_name: deploy-dev
ara_playbook_labels:
- deploy
- dev
roles:
- application

Or as extra-vars:

ansible-playbook -i hosts [Link] \

-e ansible_playbook_name=deploy-dev \
-e ansible_playbook_labels='["deploy", "dev"]'

1.10 Recording arbitrary data in playbooks

ARA comes with a built-in Ansible action plugin called ara_record.

This module can be used as an action for a task in your Ansible playbooks in order to register whatever you’d like in
a key/value format, for example:

- name: Test playbook

hosts: localhost
tasks:
- name: Get git version of playbooks
command: git rev-parse HEAD
register: git_version

- name: Record git version

ara_record:
key: "git_version"
value: "{{ git_version.stdout }}"
register: version

- name: Print recorded data

debug:
msg: "{{ version.playbook_id }} - {{ [Link] }}: {{ [Link] }}

It also supports different types of data which will have an impact on how a value might later be parsed or displayed:

26 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

- name: Record different things

ara_record:
key: "{{ [Link] }}"
value: "{{ [Link] }}"
type: "{{ [Link] }}"
loop:
- { key: "log", value: "error", type: "text" }
- { key: "website", value: "[Link] type: "url" }
- { key: "data", value: '{ "key": "value" }', type: "json" }
- { key: "somelist", value: ['one', 'two'], type: "list" }
- { key: "somedict", value: {'key': 'value' }, type: "dict" }

1.10.1 Recording data for playbooks after completion

It is possible to run an ara_record task on a specific playbook that might already be completed by specifying a
playbook. This is particularly useful for recording data that might only be available or computed after your playbook
run has been completed:

---
# Write data to a specific (previously run) playbook
- ara_record:
playbook: 14
key: logs
value: "{{ lookup('file', '/var/log/[Link]') }}"
type: text

Or as an ad-hoc command:

ansible localhost -m ara_record \

-a "playbook=14 key=logs value={{ lookup('file', '/var/log/[Link]') }}"

This data will be recorded inside ARA’s database and associated with the particular playbook run that was executed.
These records can later be retrieved through the API or through a web interface.

1.11 How to contribute

ARA Records Ansible is an open source community project and welcomes contributions, whether they are in the form
of feedback, comments, suggestions, bugs, documentation, code, or code reviews.
The ARA code review and CI infrastructure is hosted by [Link] which provides Gerrit for code review, Zuul for
CI/CD as well as many other systems.
All new patches are automatically tested with lint, unit and a variety of integration test scenarios. The end result is
higher standards, better code, more testing, less regressions and more stability.

1.11. How to contribute 27

ara Documentation, Release 1.0.0

1.11.1 Running tests locally

• Unit tests: tox -e py37

• Linters tests (pep8/flake8/bandit/bashate/black/isort/etc): tox -e linters
• Documentation tests (builds to docs/build/html): tox -e docs
• Integration tests: tox -e ansible-integration

1.11.2 Issues and pull requests

ARA has several projects that are mirrored to GitHub:

• [Link] -> [Link]
• [Link] -> [Link]
• [Link] -> [Link]
While new issues, bugs and feature requests should be filed on GitHub, we are unable to accept pull requests on
GitHub at this time.
We would appreciate the opportunity to accept them in the future by trying Gerritbot to synchronize pull requests to
Gerrit.
In the meantime, what follows are the required steps in order to send a patch to Gerrit.

1.11.3 Set up your Ubuntu Launchpad account

OpenDev’s Gerrit instance currently uses Launchpad for authentication. If you do not already have a Launchpad
account, you will need to create one here.

28 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

1.11.4 Set up your Gerrit code review account

If you’ll be contributing code or code reviews, you’ll need to set up your Gerrit code review account.
Once you have your Launchpad account, you will be able to sign in to [Link].
To be able to submit code, Gerrit needs to have your public SSH key in the same way Github does. To do that, click
on your name at the top right and go to the settings where you will see the tab to set up your SSH key.
Note that if the username from your local machine differs from the one in Gerrit, you might need to set it up in your
local ~/.ssh/config file like this:

1.11.5 Installing Git Review

Git Review is a python module that adds a “git review” command that wraps around the process of sending a commit
for review in Gerrit. You need to install it to be able to send patches for code reviews.
There are different ways to install git-review, choose your favorite.

1.11.6 Sending a patch for review

The process looks a bit like this:

$ git clone [Link]

# or git clone [Link]
$ cd ara
# Create a new local branch
$ git checkout -b super_cool_feature
# hack on super_cool_feature
$ git commit -a --message="This is my super cool feature"
$ git review

When you send a commit for review, it’ll create a code review request in Gerrit for you. When that review is created,
it will automatically be tested by a variety of jobs that the ARA maintainers have set up to test every patch that is sent.
We’ll check for things like code quality (pep8/flake8), run unit tests to catch regressions and we’ll also run both
integration tests on different operating systems to make sure everything really works.
The result of the tests are added as a comment in the review when all of them are completed. If you’re interested in
digging into the logs for a particular test, clicking on the results of the test will take you to console, debug logs and a
built version of ARA’s web interface.
If you get a failed test result and you believe you have fixed the issue, add the files, amend your commit (git commit
--amend) and send it for review once again. This will create a new patchset that will be up for review and testing.
To be able to merge a patch, the tests have to come back successful and the core reviewers must provide their agreement
with the patch.

1.11. How to contribute 29

ara Documentation, Release 1.0.0

1.12 ansible-role-ara-api

This Ansible role provides a framework for installing one or many instances of ARA Records Ansible in a variety of
opinionated deployment topologies.
It is currently tested and supported against Ubuntu 18.04 and Fedora 29.

1.12.1 Role Variables

See defaults/[Link].
# Root directory where every file for the ARA installation are located
ara_api_root_dir: "{{ ansible_user_dir }}/.ara"

# Directory where logs are written to

ara_api_log_dir: "{{ ara_api_root_dir }}/logs"

# Whether or not ara should be installed in a virtual environment.

# This defaults to true to prevent conflicting with system or distribution
# python packages.
ara_api_venv: true

# When using a virtualenv, path to where it will be installed

ara_api_venv_path: "{{ ara_api_root_dir }}/virtualenv"

# How ARA will be installed

# - source [default]: installs from a local or remote git repository
# - pypi [planned]: installs from pypi
ara_api_install_method: source

# When installing from source, the URL or filesystem path where the git source
# repository can be cloned from.
ara_api_source: "[Link]

# When installing from source, location where the source repository will be checked
˓→out to.

ara_api_source_checkout: "{{ ara_api_root_dir }}/git/ara"

# Version of ARA to install

# When installing from source, this can be a git ref (tag, branch, commit, etc)
# When installing from PyPi, it would be a version number that has been released.
# When using "latest" as the source version, HEAD will be used
# When using "latest" as the pypi version, the latest release will be used
ara_api_version: feature/1.0

# The frontend/web server for serving the ARA API

# It is recommended to specify a web server when deploying a production environment.
# - null [default]: No frontend server will be set up.
# - nginx: Nginx will be configured in front of the WSGI application server.
(continues on next page)

30 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

(continued from previous page)

# - apache [planned]
ara_api_frontend_server: null

# Path to a custom vhost configuration jinja template

# The vhost configuration templates provided by the role are simple by design
# and are not sufficient to cover every use cases.
# Use this variable if you need to have your own custom nginx or apache configuration.
ara_api_frontend_vhost: null

# The WSGI server for running ARA's API server

# - null [default]: No persistent WSGI application server will be set up. Only the
˓→offline API client will work.

# - gunicorn: gunicorn will be installed and set up to run the API as a systemd
˓→service.

# - mod_wsgi [planned]
ara_api_wsgi_server: null

# Address and port on which the wsgi server will bind

# Changing this value means you might need to adjust "ara_api_allowed_hosts" and
# "ara_api_cors_origin_whitelist".
ara_api_wsgi_bind: "[Link]:8000"

# When using a frontend server, the domain it will be listening on

ara_api_fqdn: "{{ ansible_default_ipv4['address'] }}"

####################################
# ara API configuration settings
# For more information, see documentation: [Link]
####################################

# ARA_BASE_DIR - Default directory for storing data and configuration

ara_api_base_dir: "{{ ara_api_root_dir }}/server"

# ARA_SETTINGS - Path to an ARA API configuration file

ara_api_settings: "{{ ara_api_base_dir }}/[Link]"

# ARA_ENV - Environment to load configuration for

ara_api_env: default

# ARA_READ_LOGIN_REQUIRED - Whether authentication is required for reading data

ara_api_read_login_required: false

# ARA_WRITE_LOGIN_REQUIRED - Whether authentication is required for writing data

ara_api_write_login_required: false

# ARA_LOG_LEVEL - Log level of the different components

ara_api_log_level: INFO

# ARA_LOGGING - Python logging configuration

ara_api_logging:
disable_existing_loggers: false
formatters:
normal:
format: '%(asctime)s %(levelname)s %(name)s: %(message)s'
handlers:
console:
class: [Link]
(continues on next page)

1.12. ansible-role-ara-api 31
ara Documentation, Release 1.0.0

(continued from previous page)

formatter: normal
level: "{{ ara_api_log_level }}"
filename: "{{ ara_api_log_dir }}/[Link]"
when: 'midnight'
interval: 1
backupCount: 30
loggers:
ara:
handlers:
- console
level: "{{ ara_api_log_level }}"
propagate: 0
root:
handlers:
- console
level: "{{ ara_api_log_level }}"
version: 1

# ARA_CORS_ORIGIN_ALLOW_ALL - django-cors-headers’s CORS_ORIGIN_WHITELIST_ALLOW_ALL

˓→setting

ara_api_cors_origin_allow_all: false

# ARA_CORS_ORIGIN_WHITELIST - django-cors-headers’s CORS_ORIGIN_WHITELIST setting

ara_api_cors_origin_whitelist:
- "[Link]
- "[Link]

# ARA_SERVER_ALLOWED_HOSTS - Django’s ALLOWED_HOSTS setting

ara_api_allowed_hosts:
- "[Link]"
- "localhost"
- "::1"
- "{{ ansible_default_ipv4['address'] }}"

# ARA_DEBUG - Django's DEBUG setting

# It is not recommended to run with debug enabled in production.
ara_api_debug: false

# ARA_SECRET_KEY - Django's SECRET_KEY setting

# Note: If no key is provided, a random one will be generated once and persisted
ara_api_secret_key: null

# ARA_DATABASE_ENGINE - Django’s ENGINE database setting

ara_api_database_engine: [Link].sqlite3

# ARA_DATABASE_NAME - Django’s NAME database setting

ara_api_database_name: "{{ ara_api_base_dir }}/[Link]"

# ARA_DATABASE_USER - Django’s USER database setting

ara_api_database_user: null

# ARA_DATABASE_PASSWORD - Django’s PASSWORD database setting

ara_api_database_password: null

# ARA_DATABASE_HOST - Django’s HOST database setting

ara_api_database_host: null

(continues on next page)

32 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

(continued from previous page)

# ARA_DATABASE_PORT - Django’s PORT database setting
ara_api_database_port: null

1.12.2 TL;DR

Playbook that runs the role with defaults:

- name: Install ARA with default settings and no persistent API server
hosts: all
gather_facts: yes
roles:
- ara_api

What the role ends up doing by default:

• Installs required packages (git, virtualenv, etc.) if superuser privileges are available
• Stores everything in the home directory of the user in ~/.ara
• Retrieves ARA from source
• Installs ARA in a virtualenv
• Generates a random secret key if none are already configured or provided
• Sets up API configuration in ~/.ara/server/[Link]
• Runs the API SQL migrations (ara-manage migrate)

1.12.3 About deployment topologies

This Ansible role is designed to support different opinionated topologies that can be selected with role variables.
For example, the following role variables are used to provide the topology from the TL;DR above:
• ara_api_install_method: source
• ara_api_wsgi_server: null
• ara_api_database_engine: [Link].sqlite3
• ara_api_web_server: null
The intent is that as the role gains support for other install methods, wsgi servers, database engines or web servers, it
will be possible to mix and match according to preference or requirements.
Perhaps ARA could be installed from pypi and run with gunicorn, nginx and mysql. Or maybe it could be installed
from distribution packages and set up to run with apache, mod_wsgi and postgresql. Or any combination of any of
those.

1.12.4 Example playbooks

Install ARA and set up the API to be served by a persistent gunicorn service:

1.12. ansible-role-ara-api 33
ara Documentation, Release 1.0.0

- name: Install ARA and set up the API to be served by gunicorn

hosts: all
gather_facts: yes
vars:
ara_api_wsgi_server: gunicorn
roles:
- ara_api

Install ARA and set up the API to be served by nginx in front of gunicorn:

# Requires superuser privileges to set up nginx and the ara-api service

# The API will be reachable at [Link]
- name: Install ARA and set up the API to be served by nginx in front of gunicorn
hosts: all
gather_facts: yes
vars:
ara_api_frontend_server: nginx
ara_api_wsgi_server: gunicorn
ara_api_fqdn: [Link]
ara_api_allowed_hosts:
- [Link]
ara_api_frontend_vhost: custom_vhost.conf.j2
roles:
- ara_api

1.13 ansible-role-ara-web

This Ansible role provides a framework for installing one or many instances of ara-web in a variety of opinionated
deployment topologies.
It is currently tested and supported against Ubuntu 18.04 and Fedora 29.

1.13.1 Role Variables

See defaults/[Link].

# Root of where files will be stored for ara-web

ara_web_root_dir: "{{ ansible_user_dir }}/.ara"

# When using static builds without the dev server, path to ara-web static assets
ara_web_static_dir: "{{ ara_web_root_dir }}/www/ara-web"

# How ara-web will be installed

(continues on next page)

34 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

(continued from previous page)

# - source (default): installs from a local or remote git repository specified by ara_
˓→web_source

# - npm (planned): installs from npm

ara_web_install_method: source

# When installing from source, the location of the remote or local git repository
ara_web_source: "[Link]

# Location where ara-web will be checked out

ara_web_source_checkout: "{{ ara_web_root_dir }}/git/ara-web"

# Location where node_modules will be installed

ara_web_node_modules_dir: "{{ ara_web_source_checkout }}"

# Version of ara-web to install

# This can be a git ref (tag, branch, commit) when installed from source
# When using "latest" as the source version, HEAD will be used
ara_web_version: latest

# Whether to use the embedded react web server or not

# Setting this to false means ara-web will be statically built instead
ara_web_dev_server: true

# When the development server is enabled, the address it will be listening on

ara_web_dev_server_bind_address: [Link]

# When the development server is enabled, the port it will be listening on

ara_web_dev_server_bind_port: 3000

# Version of nodesource nodejs repositories to install

ara_web_nodejs_version: 10

# ara-server API endpoint to use

ara_web_api_endpoint: "[Link]

# The frontend server for serving ara-web

# - null (default): none, users are expected to use the development server directly
˓→or deploy their own web server

# - nginx: when performance of the development server is an issue

# - apache (planned)
ara_web_frontend_server: null

# When using a frontend server, you can override the default vhost configuration
# template by specifying the path to your own template file.
ara_web_frontend_vhost: null

# When using a frontend server, the hostname to listen on

ara_web_fqdn: "{{ ansible_default_ipv4['address'] }}"

1.13.2 TL;DR

This is what the role does by default out of the box:

• Retrieves ara-web from source
• Installs nodejs LTS (v10)

1.13. ansible-role-ara-web 35
ara Documentation, Release 1.0.0

• Installs ara-web dependencies with npm

• Configures an ara-server API endpoint in ara-web’s public/[Link] file
• Sets up a systemd unit file for running ara-web with the embedded development server

1.13.3 About deployment topologies

This Ansible role is designed to support different opinionated topologies that can be selected with role variables.
For example, the following role variables are defaults used to provide the topology from the TL;DR above:
• ara_web_install_method: source
• ara_web_dev_server: true
• ara_web_frontend_server: null
The intent is that as the role gains support for other install methods or frontend servers, it will be possible to mix and
match according to preference or requirements.

1.13.4 Example playbooks

Deploy the ARA API and web client on the same machine with defaults:

- name: Deploy ARA API and web client

hosts: all
gather_facts: yes
vars:
# ara_api
ara_api_fqdn: [Link]
ara_api_wsgi_server: gunicorn
ara_api_allowed_hosts:
- [Link]
ara_api_cors_origin_whitelist:
- [Link]
# ara_web
ara_web_fqdn: [Link]
ara_web_api_endpoint: "[Link]
roles:
- ara_api
- ara_web

Deploy only ara-web behind nginx and point it to a remote API endpoint:

# Note: Don't forget to add the web fqdn in the remote cors_origin_whitelist.
# Otherwise, the web client might not be authorized to query the API.
- name: Deploy ara-web for remote API endpoint
hosts: all
gather_facts: yes
vars:
ara_web_fqdn: [Link]
ara_web_api_endpoint: "[Link]
ara_web_frontend_server: nginx
ara_web_frontend_vhost: [Link].j2
roles:
- ara_web

36 Chapter 1. Table of Contents

 ara Documentation, Release 1.0.0

1.14 ansible-role-ara-tests

An Ansible role that installs ARA and Ansible to run quick and inexpensive tests that do not require superuser privi-
leges.

1.14.1 Role Variables

See defaults/[Link].

# Root directory where integration tests will prepare and store data
ara_tests_root: "/tmp/ara-integration-tests"

# Directory where the virtualenv will be created

ara_tests_virtualenv: "{{ ara_tests_root }}/ara-tests-virtualenv"

# Directory where ARA_BASE_DIR will be set

ara_tests_data: "{{ ara_tests_root }}/.ara/server"

# Name of the Ansible package

# This can be "ansible" which will use pip or it could be something like
# /home/user/git/ansible as well as git+[Link]
ara_tests_ansible_name: ansible

# Version of Ansible from pypi to install

ara_tests_ansible_version: latest

1.14.2 TL;DR

- name: Test ARA with the latest version of Ansible

hosts: all
gather_facts: yes
roles:
- ara_tests

What the role ends up doing by default:

• Creates a directory to contain the files for the duration of the tests
• Installs ARA from source and the latest version of Ansible in a virtualenv
• Runs test playbooks designed to exercise different features of ARA

1.14. ansible-role-ara-tests 37