Score:0

AWX/Ansible Tower unable to see playbooks in tasks role subdirectory?

pl flag

I'm adding some of my Ansible playbooks into AWX/Ansible Tower, using Azure DevOps as a back end git repo, but I've found after converting them into a more role based structure that certain playbooks seem to be invisible within the Playbook selection option in AWX Job Templates. This appears to depend on where they are located within the directory structure.

The primary issue is that I am unable to specify and execute any playbooks directly from the tasks subdirectory - my intention was to use tasks/main.yml as list of import_tasks referencing the other playbooks in that directory.

I used ansible-galaxy init role to generate a standard template, added it to the repo, but I discovered that after uploading and syncing only the template file located in tests/test.yml was visible initially (including any of the main.yml template files automatically generated), and any files located in the tasks subdirectory were unavailable for selection. When I started adding my own playbook files these are also unavailable in AWX.

If I try to type in the path and filename manually, I get an error that states "Playbook not found for project." when I try to save the project.

Steps taken:

  1. The Project has been synced with the repo countless times.

  2. I know that some syntax checking is performed by AWX on YML files, but I've tested using the following basic template, and if I create a test YMl file in the root directory, or either tests/, defaults/ or handlers/ AWX can see it, so this should rule the file contents out. If however I place it in tasks, or another randomly named (e.g. roles, blahblahtest) subdirectory it's not picked up by AWX.

- name: Alma Linux VM Post Deployment Tasks
  hosts: all
  become: yes
  1. I've also checked file permissions at a command line level and there are no irregularities.

It seems as though there is some kind of restriction on accessing certain directories.

Here's a full rundown of the directory structure showing which files are visible for selection by AWX. All files marked as VISIBLE or INVISIBLE have the same contents, and any other files other than Jinja templates have valid YML/Ansible syntax but are also not seen by AWX.

root@dcbutlawx03:/awx/projects/_126__common_alma_linux# tree
.
├── defaults
│   └── main.yml (VISIBLE)
├── handlers
│   └── main.yml (VISIBLE)
├── main.yml (VISIBLE)
├── meta
│   └── main.yml
├── README.md
├── tasks
│   ├── dca-alma-ad.yml
│   ├── install-graylog-agent.yml
│   ├── install-zabbix-agent.yml
│   ├── main.yml (INVISIBLE - SAME CONTENTS!)
│   ├── playbook.yml 
│   ├── post-vmdeploy-tasks.yml
│   ├── testtest.yml (INVISIBLE - SAME CONTENTS!)
│   └── test.yml (INVISIBLE - SAME CONTENTS!)
├── templates
│   └── alma-ad
│       ├── krb5.conf.j2
│       ├── smb.conf.j2
│       ├── sshd_config.j2
│       ├── sssd.conf.j2
│       └── zts_sudoers.j2
├── tests
│   ├── inventory
│   ├── playbook.yml (VISIBLE)
│   └── test.yml (VISIBLE)
└── vars
    ├── dca-alma-ad
    │   └── dca-vars.yml
    ├── main.yml
    └── tf-alma-ad
        └── tf-vars.yml

The AWX server belongs to my workplace, but it seems unlikely they would be randomly imposing idiosyncratic restrictions such as this, if it's even possible to do. The person who built the server and wrote most of the existing playbooks is no longer with the company, so there's knowledge gap in this area amongst current employees.

I could technically use a main.yml or similar file from the root directory, but I believe this is against guidelines, and I will be shortly looking to create a product based master repo containing multi roles that share common group variables etc, so this would only be a short term fix.

I've looked for log files on the server to try to cross reference the above error, but neither of the following directories exist, which seems to be where they are usually located.

/var/log/tower/
/var/log/supervisor/

Does anybody have any ideas what the issue could be, or where I could go next in terms of troubleshooting steps?

Thanks in advance.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.