After discussing it with several clients yesterday, we have designed and implemented a new type of Inventory, named Federated Inventory. The PR is now merged and it will be released in the next version.
What Is a Federated Inventory?
A federated inventory is a new inventory type in Ascender, sitting alongside normal, smart, and constructed inventories. It acts as an envelope around two or more plain source inventories. It holds no hosts or groups of its own. Instead, it knows about its input inventories and uses that knowledge at job launch time to do something no other inventory type can do: dispatch a separate child job for each source inventory, with each child job running on that source inventory's own Instance Groups. It basically uses the internal Job Slicing system to slice jobs by the "source inventory" instead of by "size".
The problem it solves has been a major thorn for a while.
Imagine two inventories: East, with hosts host1 and host2, pinned to the ig-east Instance Group, and West, with hosts host3 and host4, pinned to ig-west. Build a combined inventory out of those two today and launch a job against it, the job runs on one Instance Group. Your regional routing is gone. With a federated inventory containing East and West as inputs, launching the same job template produces two simultaneous child jobs: one running against East on ig-east, another running against West on ig-west. The combined output is tied back into a single Workflow Job in the UI, exactly like sliced jobs work today.
Or imagine you have 15 different Instance Groups for all your different environments, each with their own Inventory paired. You have an external tool that calls the API to run linux updates on a single host. Your external tool would have to know which Inventory your host lives in. Your Job Template could prompt on launch for the Inventory, or like a lot of people, you may duplicate the job templates and point each one to a different inventory and the tool would have to call the proper API endpoint for that Job. That's no longer necessary. You can now point the Job Template at the Federated Inventory, and it doesn't matter where the host lives. It is going slice the job and update it with the proper inventory for the host, which is then going to run it on the proper Instance Group for that inventory.
How It Works Under the Hood
When Ascender launches a job template backed by a federated inventory, it intercepts the launch before a regular Job is created and builds a WorkflowJob instead. One WorkflowJobNode is created per source inventory, and each node's child job is handed that source inventory directly. The child job inherits the source inventory's Instance Group assignments naturally, because it is running against that inventory and nothing else.
If the job template has a limit set, either on the template itself or supplied at launch time, Ascender evaluates each source inventory before creating a node for it. If that inventory contributes no matching hosts or groups, it is skipped entirely — no empty job is dispatched for it. Simple glob patterns like "web*" are resolved against the DB with an indexed prefix query. Exact names get a direct index lookup. Complex patterns using Ansible's colon, ampersand, or exclamation operators are passed through to all source inventories and let Ansible resolve them at run time, the same way it always has.
What It Does Not Do
Federated inventories are not a general-purpose inventory plugin. They solve the Instance Group routing problem specifically. They do not compose hostvars, they do not run inventory syncs, and they do not support ad hoc commands (those bypass the job template launch path entirely and would run against an empty inventory). If you need hostvars merging, group renaming, or conditional filtering based on host facts, a constructed inventory is still the right tool. Federated inventories are for when you already have the right host data in the right inventories and you just need the jobs to run in the right places.
See a bit more documentation here
ctrliq/ascenderblob/main/docs/inventory/federated_inventory.md
