Background

This was started as an email chain that I have conveted into an epic...
Problem Statement
In AAP2.2, the mapping of "what execution nodes should automate against what managed hosts" is statically assigned at the inventory or job template level, requiring duplicate job templates with set inventories (requiring multiple inventories) or setting up a workflow that passes an inventory to the same job template multiple times. This is administrative overhead when in reality, there is only one playbook being run, and no difference in job template or execution except for  which execution node runs the job.
 
Example AAP Architecture
For the purposes of discussion and for proposing a solution, consider the following AAP architecture:

 
Let's also assume I have a set of managed nodes: 1 in each of [DC1, DC2, AWS, Azure, Mfgplant1], just for discussion, knowing that customers would have many managed nodes in each "location".
 
Each "bank" of execution environments are assigned to an instance group in AAP:

 
Required Configuration Today
Today, I have to create a set of inventories, such as:

 
Then I have to assign the appropriate instance group to the inventory:

I can "re-use" a single job template by having it prompt for an inventory on launch and then having a workflow node assign the inventory:

 
A workflow that runs 4 identical jobs across my inventories then looks like:

 
 
 
Proposed Solution
AAP should automatically determine the appropriate execution node(s) and allocate/communicate work accordingly.
 
In the short term, this could be accomplished by having a variable that can be defined at the [host, group] level which tells AAP to route the job to the specified execution node(s):
 
ansible_execution_nodes:
  - aws-execution-node1.86b6.demos.lcl
  - aws-execution-node2.86b6.demos.lcl
 
This would allow for hosts to exist within one inventory and use one job template to run common automation across all endpoints, while AAP seamlessly breaks up the work amongst the execution nodes under the hood.
 
In the long term, a set of variables could be defined to provide more fine-grained control around what execution nodes are leveraged for a given [host, group]:
 
ansible_close_execution_nodes:
  - aws-execution-node1.86b6.demos.lcl
  - aws-execution-node2.86b6.demos.lcl
 
ansible_far_execution_nodes:
  - dc1-execution-node1.86b6.demos.lcl
  - dc1-execution-node2.86b6.demos.lcl
 
Here, AAP should attempt to use the execution nodes in the "close" group first, however they're unavailable or currently at capacity, then the nodes in the "far" group are leveraged to run the automation.
 
I'm not sure how this could be done without manual definition of execution nodes (or maybe some combination of "steering" + connectivity pings/tests), but that would be appealing as well: have AAP automatically determine (with some input) how to route jobs to execution nodes to ensure the "closest" nodes to what's being managed are utilized first.
 
Thanks,
 
-Josh
 --

Josh Swanson

Chief Architect

Red Hat
 
joshswanson@redhat.com

M: [262-389-9225|tel:262-389-9225] 

Peloton Leaderboard Name: jswanson4