3. Known Issues
3.2. Errors when editing objects
Ansible Tower implements a role based access control system. It may appear that you can edit objects that do not belong to you–like being able to pull up an edit dialog of your teammates, which you have been granted permission to view–but when you try to edit something, you will receive a 403 error and you cannot view any information you should not already have access to as defined in the system.
3.3. Host comparisons against a single host
When performing a host comparison against a single host, if there is only one (1) run for the selected date, Tower may display a message saying it could not find any scan job runs in one of the columns.
3.4. Host comparisons against a two hosts
When performing a host comparison against two hosts, you can only select from a single page of hosts.
3.5. Live events status indicators
Live events status dots are either seen as a red or orange dot at the top of the Tower Dashboard when something goes wrong, or they are not seen at all to indicate a healthy system state. If you encounter a red or orange live events status indicator, even when your system seems fine, the following suggestions may offer a solution:
- Try manually refreshing/reloading your browser page.
- Try changing web browsers, as Firefox and Safari have been reported to have issues trusting self-signed certificates.
- Try creating a self-signed certificate that matches your DNS and import it into your trust manually.
- Try using an incognito or private browsing session.
- Try disabling your browser plugins to ensure none are blocking the service.
Live event status dots are used for troubleshooting problems with your Tower instance and the socketio logs can point out anything problematic. You can collect troubleshooting help by running a sosreport. As root, run the command
sosreport from your system to automatically generate a diagnostic tar file, then contact Ansible’s Support team with the collected information for further assistance.
Starting with Ansible Tower 2.2.0, live events status indicators only appear if Tower detects a problem. In earlier releases, a green status dot was shown to indicate a healthy system.
3.6. Playbooks missing access to necessary data due to PRoot issues
When running a playbook that reads and writes information in certain prohibited directories, users may encounter issues with PRoot. PRoot runs the
ansible-playbook command within a
chroot jail. In cases like these, the running playbook cannot see other playbooks or sensitive data on disk and should the playbook expect to have access to that information, problems will occur. To fine tune your usage of PRoot, there are certain variables that can be set:
# Enable proot support for running jobs (playbook runs only).
AWX_PROOT_ENABLED = False
# Command/path to proot.
AWX_PROOT_CMD = 'proot'
# Additional paths to hide from jobs using proot.
AWX_PROOT_HIDE_PATHS = 
# Additional paths to show for jobs using proot.
AWX_PROOT_SHOW_PATHS = 
3.7. Slower than expected performance
Slow performance issues have been reported against Ansible Tower 2.2.0. You may experience slower than expected system performance if:
- You have a large number of job templates, users, credentials, permissions, projects, and/or inventories. If you find that loading the job template page for normal users is unacceptably slow, run the “Cleanup Deleted Data” management job with
days = 0. Refer to Management Jobs in the Ansible Tower Administration Guide for more information.
- You have a job that produces a lot of playbook output (several megabytes or more). Performance can often be improved by switching to “Normal” verbosity, assuming that your Job Template is set to a higher verbosity level.