Allow Promptable Instance Group from Predetermined List.

[gamuniz]

ISSUE TYPE

• Feature Idea

SUMMARY

Allow for users with admin on a job template to select from a predetermined list of instance groups. This would allow for the reuse of job templates and reduce the need for redundant job templates.

[al-lac]

Seems like a great idea. I think it would also make sense to be able to pin Instance Groups to Groups or individual hosts. It would solve the duplicate templates problem as well. Especially if you have a lot of hosts that are only reachable via an isolated node.

[wenottingham]

Pinning to groups or hosts does not make sense - a playbook only runs on one instance group.

[al-lac]

I was just thinking about how Foreman / Satellite handles hosts in isolated environments. Here you can set the required capsule on a per host / group / network basis. With the way it's currently implemented in awx you have to copy your template for every isolated environment that one has. And i know that you can set instance groups on inventories, but since you can only specify one per template it also solves nothing. And combining inventories by using the smart inventories feature ignores the instance groups of the main inventories.

[wenottingham]

Right, but what you're suggesting is to execute the playbook once on each instance group that may be used by the inventory, limited to those hosts. That can alter how the playbook runs, what gathered facts it uses, what conditionals it follows; it can't be done transparently.

[al-lac]

Maybe it can be solved similar to how job splicing works by creating a workflow with a job for each instance group. But i can see the problem here, yeah.

I would already be happy if we could just select more than one inventory per template like requested in #412. That way we could use a single template for internal and isolated environments.

[cdggcali]

Just an example of a use case:

We have a job template to patch servers, on the inventory this template uses, we have some of the servers that can only be accessed by some of the node on the ansible tower instance group.

For example, if I have the following instance groups: [tower] server1 server2 server3

[WEST] server1

[EAST] server2

By default, we use the tower instance group, but let's say I need to patch a server that can be only accessed by the [EAST] instance group, how can I configure AWX/Ansible Tower to do this?

Just to make sure, we don't want only to use [EAST] instance group for patching all the instance servers, since [tower] allows us to load balance the patching jobs better and we also want only one job template, because our AWX/Ansible Tower instance is used as a service, where other tools can start this tool using the API, if we had 2 or more job template, we will need to coordinate with the API users and let them know which job to use, instead of being a single API call for any server.

[blaira89]

My customer is deeply interested in seeing this RFE move forward. Here is their business justification:

We’re looking to consolidate 8 isolated full Tower clustered environments in place today along with dozens of firewall rules and code changes. To accomplish that we want to use the Tower feature of isolated groups in each of our zones. In order to have a consistent code base between all the zones and regions we need to keep the organizations and inventories the same. Therefore the only place we can set the instance groups mapped to the isolated groups is at the job template level. This means that we have to release ~9 job templates for each job template we release. So on a monthly basis we’re looking at minimum ~36+ job templates to release instead of 4 where we could just pass the instance group at launch time.

[sspreitzer]

Adding "Prompt for Instance Group" in the job templates sounds like a low hanging fruit to me.

[NicoWde]

we currently ran into the very same issue, as the customer of @blaira89

[daemenseth]

We have also the same issue as @blaira89 Is there more information about that or another solution

[rhessing]

Wondering why it isn't possible to create a smart inventory that has an option to inherit the instance groups on a host basis from the other inventories where the smart inventory is based on? In my opinion, smart inventories would be the way to go for this issue...

[AlanCoding]

@matburt I want to ask your thoughts on how we might implement this because it touches back to the original design of instance group preferences.

This would be a non-obvious design. Would the user provide an instance group? We have a field on the UnifiedJob model, so this would work intuitively. If going this route, would the IG have to be in the existing preferred instance group list?

Or should the prompt accept an instance? Probably not, I think I'm talking myself out of this idea.

[matburt]

My feeling here is that it should remove the preferential instance group logic entirely... so no overflow or rollover, and only allows IGs for which the user has access to. There might not be enough rbac to cover the actual permissions here, though? I'm open to discussion but definitely can't select an instance due to things like Container Groups.

[john-westcott-iv]

Permissions to "see" an IG are pretty high (I think you have to be an org admin at a minimum) and you are correct in that we don't have RBACs to allow the addition of users to see/use them. So prompt on launch to specify a different set of IGs will be pretty useless to non super users until we add that feature.

However, one advantage in the way we have it currently coded is that you can also use it as a restriction. For example, say a sysadmin setup a JT with 10 IGs w/ prompt on launch and you can execute that JT but not see any IGs. The API will allow you to specify a subset of IGs that are already applied to the field. So if you wanted to specify IG 4, 5 and 6 from the list of 10 the API will allow that even though your user can't see any.

And we did also code it such that a specified list in prompt on launch will short circuit the preferred IG logic.

[matburt]

https://github.com/ansible/awx/blob/cae2c0619026ff864d24f390c3fe46b506e41f74/awx/main/access.py#L564

This is a pretty minimal set with some room to expand. So something like:

• can_read ... in org... at least job template admin
• can_use ... defaulted to org admin, job template admin can use if IG associated with JT(?)

use is governed by what IG is pre-assigned by the org admin... jt admins can select any of them individually from that list but it always short circuits the preferrential and only executes against that one.. org admin could select from any associated with an org.... superuser can select any from the entire system.

anything else falls through to existing logic.

[AlanCoding]

This was implemented in a recent merge https://github.com/ansible/awx/pull/12875

@john-westcott-iv @hesmithrh I'm confused about what to do this issue, but it should be either Needs Test or closed.