Allow specifying relative playbook directory path for inventory sources

[megakoresh]

ISSUE TYPE

• Feature Idea

SUMMARY

As a follow up to this discussion, I think it makes sense to avoid having some kind of special logic to determine value for --playbook-dir option for inventory sources, when sourced from project, and simply allow users to put that value in relative to project root, same as you would do in cli. This is also consistent with how you can input a relative path for the inventory source file itself.

[AlanCoding]

This is a duplicate specification, because the user selects the playbook when they create a job template. If the user has selected for the inventory to update on launch, then this would be theoretically possible to infer from the job template at the time of update.

That also implies that there are multiple different forms of inventory, depending on what playbook is using it. Practically speaking, that's kind of crazy for any user to want their inventory to behave differently depending on what playbook is using it.

[megakoresh]

This is a duplicate specification, because the user selects the playbook when they create a job template. If the user has selected for the inventory to update on launch, then this would be theoretically possible to infer from the job template at the time of update.

That also implies that there are multiple different forms of inventory, depending on what playbook is using it. Practically speaking, that's kind of crazy for any user to want their inventory to behave differently depending on what playbook is using it.

Sorry, I am not familiar with AWX internals. I thought inventory is separated in awx from playbook execution. In that first the inventory is updated and stored in a database, and then the playbook is run against whatever is in the database from the last update, not directly against what the inventory script/plugin return. Is that not the case?

[AlanCoding]

Sorry, I am not familiar with AWX internals. I thought inventory is separated in awx from playbook execution.

The user should not have to think about this. You understand more than what can be expected from a general user, and the idea of an extra form input for playbook path involves the user jumping through extra hoops for reasons which are murky and confusing to most users.

Related fixes already going in involve actively managing the collection and roles path. Actively managing the inventory plugins path as well seems to me like the inevitable end-game, and would make it "just work" by trying all possible playbook locations.

[AlanCoding]

Also, it doesn't make sense to add an input for the playbook path, but not add an input box for the config file path.

The config file is obtained from the directory where the user runs playbooks, but the plugin folders are obtained from the directory of the playbook. For either of these things, the user could fail to run their imports in AWX, and claim "but it worked on the CLI!"

The config file argument also applies equally to job runs, but we've had a long-standing practice of only using the top-level config file.

[megakoresh]

@AlanCoding I think I may have to elaborate on my overall agenda here. I have been primarily responsible for taking AWX/Tower into use in a fairly big enterprise with lots of different technologies, the automation of which is going to be handled or is handled via Ansible. In such environment, as in any enterprise setting, I might imagine, the only way is to stick to best practices and follow conventions.

So with that in mind, we have been constructing ansible playbooks using examples in ansible's own annoyingly vaigue documentation littered with breaking changes as well as vendor's own examples.

And so what I really would like to avoid is having to rewrite them "for awx". I don't currently understand the direction and purpose of AWX as inteded by it's core team, as some of it's design and architectural decisions seem to contract what I understood it's purpose to be from RedHat's own sales pitches.

To me it always seemed like AWX's core philosophy is to be an "Ansible Web Executor". So if it works in CLI, it should work in AWX. That is the idea. We cannot possible rewrite all the playbooks we have to work with AWX if these sort of issues come up. Right now every time we try to make a playbook work in AWX I have to either adapt or entirely rewrite it (often not understanding the technology it's managing underneath, since it's written by a specialist in a completely different field) just so it works.

So with that out of the way - back to the original discussion. I think config path for inventory source and a job is also an option that should be settable. And I really strongly disagree with the following statement:

The user should not have to think about this. You understand more than what can be expected from a general user, and the idea of an extra form input for playbook path involves the user jumping through extra hoops for reasons which are murky and confusing to most users

The idea of AWX/Ansible Tower is not, according to what RedHat reps told me, to provide a dumbed down way to execute Ansible. It's a way to separate Ansible admins and developers from ansible users. That's what all these "ask at launch" and "survey" things are for.

Admins must be expected to understand Ansible no less than developers do (they are typically same people), and there's absolutely no reason to hide these options from them. Admins are the ones who create inventories. User's just launch templates and see statistics. Often not even that, since AWX is used by automation pipeline and only REST API is ever called.

Ansible playbooks are developed and tested on command line. Noone should have to "develop" in or for AWX. An Admin needs to be able to develop and test a playbook repository with all of it's included components, add it to AWX, configure it so it works same as in CLI, lock down what they don't want the Users to be able to see/worry about and set permissions. I always considered inventory sources as just ansible-inventory with options as database entries, jobs as ansible-playbook with options as database entries, and so on. As an admin and a developer that's what I expect. The "Press me to create a server/switch/firewall cluster" button is for the users after I have set everything up for them.

Now if the "recommended practice" is to have separate repositories for each set of ansible plugins or .cfg files, I can accept that as a "solution" if it's documented somewhere. But just saying that "we can't let admins specify CLI options because they should't have to worry about it" is, in my opinion, just wrong.

[AlanCoding]

Addressing that option (an input for the playbook dir relative path) more seriously, I expect that we would want to re-use the playbook file selector. So it would probably look something like:

Obviously the tooltip would have to elaborate on what this does. The CLI options help gives

  --playbook-dir BASEDIR
                        Since this tool does not use playbooks, use this as a
                        substitute playbook directory.This sets the relative
                        path for many features including roles/ group_vars/
                        etc.

The other option of https://github.com/ansible/awx/pull/5024 does have many risks and issues with it.