A Project is a logical collection of Ansible playbooks, represented in Tower.
You can manage playbooks and playbook directories by either placing them manually under the Project Base Path on your Tower server, or by placing your playbooks into a source code management (SCM) system supported by Tower, including Git, Subversion, Mercurial, and Red Hat Insights. To create a Red Hat Insights project, refer to Setting up an Insights Project.
By default, the Project Base Path is
/var/lib/awx/projects, but this may have been modified by the Tower administrator. It is configured in
/etc/tower/settings.py. Use caution when editing this file, as incorrect settings can disable your installation.
This menu displays a list of the projects that are currently available. The list of projects may be sorted and searched by any of the table headers displayed.
Status indicates the state of the project and may be one of the following (note that you can also filter your view by specific status types):
/var/lib/awx/projects(applicable for manual or source control managed projects).
For each project listed, you can edit () project properties, copy the project attributes (), get the latest SCM revision (), or delete () the project, using the respective icons under the Actions column.
Projects of credential type Manual cannot update or schedule source control-based actions without being reconfigured as an SCM type credential.
If deleting items that are used by other work items, a message opens listing the items are affected by the deletion and prompts you to confirm the deletion. Some screens will contain items that are invalid or previously deleted, so they will fail to run. Below is an example of such a message:
To create a new project:
If adding a manual project, each project path inside of the project root folder can only be assigned to one project. If you receive the following message, ensure that you have not already assigned the project path to an existing project:
All of the project paths have been assigned to existing projects, or there are no directories found in the base path.
You will need to add a project path before creating a new project.
If you have trouble adding a project path, check the permissions and SELinux context settings for the project directory and files.
If you have not added any Ansible playbook directories to the base project path, you will receive the following message from Tower:
Correct this issue by creating the appropriate playbook directories and checking out playbooks from your SCM or otherwise copying playbooks into the appropriate playbook directories.
- SCM URL - See an example in the help text.
- SCM Branch - Optionally enter the SCM branch for Mercurial, or the SCM branch, tag, or revision for Git
- Revision # - Optionally enter the Revision # for Subversion
- SCM Credential - If authentication is required, select the appropriate SCM credential
- SCM Update Options:
- Clean - Remove any local modifications prior to performing an update.
- Delete on Update - Delete the local repository in its entirety prior to performing an update. Depending on the size of the repository this may significantly increase the amount of time required to complete an update.
- Update on Launch - Each time a job runs using this project, perform an update to the local repository prior to starting the job. To avoid job overflows if jobs are spawned faster than the project can sync, selecting this allows you to configure a Cache Timeout to cache prior project syncs for a certain number of seconds.
Using a Github link offers an easy way to use a playbook. To help get you started, use the
helloworld.ymlfile available at: https://github.com/ansible/tower-example.git
This link offers a very similar playbook to the one created manually in the instructions found in the Ansible Tower Quick Start Guide. Using it will not alter or harm your system in anyway.
Please note that immediately after adding a project setup to use source control, a “Sync” starts that fetches the project details from the configured source control.
The set of Permissions assigned to this project (role-based access controls) that provide the ability to read, modify, and administer projects, inventories, job templates, and other Tower elements are Privileges.
You can access the project permissions via the Permissions tab next to the Details tab. This screen displays a list of users that currently have permissions to this project. The list may be sorted and searched by User, Role, or Team Role.
The Permissions tab allows you to review, grant, edit, and remove associated permissions for users as well as team members. To assign permissions to a particular user for this resource:
- Click to select one or multiple checkboxes beside the name(s) of the user(s) or team(s) to select them.
You can select multiple users and teams at the same time by navigating between the Users and Teams tabs without saving.
After selections are made, the window expands to allow you to select a role from the drop-down menu list for each user or team you chose.
The example above shows options associated with inventories. Different resources have different options available:
- Admin allows read, run, and edit privileges (applies to all resources)
- Use allows use of a resource in a job template (applies all resources except job templates)
- Update allows updating of project via the SCM Update (applies to projects and inventories)
- Ad Hoc allows use of Ad Hoc commands (applies to inventories)
- Execute allows launching of a job template (applies to job templates)
Use the Key button in the roles selection pane to display a description of each of the roles.
- Select the role to apply to the selected user or team.
NoteYou can assign roles to multiple users and teams by navigating between the Users and Teams tabs without saving.
Click Save when done, and the Add Users/Teams window closes to display the updated roles assigned for each user and team.
To remove Permissions for a particular user, click the Disassociate (x) button next to its resource.
This launches a confirmation dialog, asking you to confirm the disassociation.
Clicking on Notifications allows you to review any notification integrations you have setup.
To create a new notification, click the NOTIFICATIONS link from the upper-right side of the notifications list view. If no notifications have been set up, click the NOTIFICATIONS link from above or inside the gray box to add a new notification to create a notification.
Refer to Notifications for more information.
Clicking on Job Templates allows you to review any job templates or workflow templates associated with this project.
From this view, you can launch or copy the template configuration.
Clicking on Schedules allows you to review any schedules set up for this project.
From this view, you can select schedules to edit, turn on or off, or select multiple schedules to delete.
This screen displays a list of the schedules that are currently available for the selected Project. The schedule list may be sorted and searched by Name.
The list of schedules includes:
To create a new schedule:
The SCHEDULE DESCRIPTION allows you to review the set schedule and a list of the scheduled occurrences in the selected Local Time Zone.
Jobs are scheduled in UTC. Repeating jobs that run at a specific time of day may move relative to a local timezone when Daylight Savings Time shifts occur. Essentially, Tower resolves the local time zone based time to UTC when the schedule is saved. To ensure your schedules are correctly set, you should set your schedules in UTC time.
You can use the ON/OFF toggle button to stop an active schedule or activate a stopped schedule.
The schedules overview screen for the project also shows you when the first, next, and final runs are scheduled.
At the end of a Project update, Tower searches for a file called
requirements.yml in the
roles directory, located at``<project-top-level-directory>/roles/requirements.yml``. If this file is found, the following command automatically runs:
ansible-galaxy install -r roles/requirements.yml -p ./roles/ --force
This file allows you to reference Galaxy roles or roles within other repositories which can be checked out in conjunction with your own project. The addition of this Ansible Galaxy support eliminates the need to create git submodules for achieving this result.
For more information and examples on the syntax of the
requirements.yml file, refer to Advanced Control Over Role Requirements in the Ansible documentation.