Ansible managed nodes, reconciled to the order form.
Ansible managed node reconciliation is the subscription assessment surface that produces the widest variance between what the controller reports, what the order form names, and what the estate actually automates. The controller will count anything that sits in an inventory, whether the host is in scope for the entitlement or not, and a buyer who reads the controller number alone will overstate consumption every quarter the inventory was loaded but never trimmed. This note sets out a buyer side method for reconciling the managed node count against the signed entitlement on Ansible Automation Platform.
What the reconciliation is for.
Ansible managed node reconciliation exists because the order form names a number that the platform does not natively enforce. Ansible Automation Platform is sold against a count of managed nodes that the buyer commits to at signature, and the controller subscription record will show that committed count back as the entitled ceiling. What the controller will not do is tell the buyer which of the hosts it observed during the trailing window were actually in scope for the entitled count and which were duplicates, retired estate, lab inventory, or hosts the platform read once and then never automated against.1
The reconciliation closes that gap on paper before Red Hat closes it in a renewal quote or a compliance inquiry. The exercise lives inside the subscription assessment practice, runs on a quarterly or pre renewal cadence, and produces one ledger that names every host the controller counted, classifies it by source and by entitlement category, and reads the resulting count against the signed quantity. The reconciliation is not filed with Red Hat. It is the buyer's own working paper, used to set posture into the next renewal or into the audit defense response.
For the broader counting mechanics on Ansible, see the managed node counting mechanics note. For the surrounding practice on Ansible Automation Platform, see the Ansible practice hub. This note focuses on the reconciliation layer that sits between the two: how the count actually lands once the inventory has been read against the order form.
The managed node, defined for the reconciliation.
A managed node, for the purpose of the reconciliation, is a host that Ansible Automation Platform automated against during the operative window. The qualifying verb is automated, not catalogued. A host that the controller resolved into an inventory but never ran a job against is a candidate node, not a managed node, and the reconciliation needs the distinction because the order form is priced against the operating count rather than the inventory count.2
The operative window in the practice is typically the trailing twelve months on a pre renewal reconciliation, and the trailing audit window on a compliance reconciliation. The window matters because Ansible inventories drift faster than RHEL host counts, and a single point in time read of the controller will reflect whichever hosts happened to be loaded the day the report was run. The reconciliation reads the window, not the day. A host that appeared on the controller for one week and was then retired carries different weight from a host that has been automated weekly across the full window.
Red Hat documentation on Ansible Automation Platform names the managed node as the unit of subscription, with execution by the platform as the qualifying event. The reconciliation reads the same definition and adds the practical filter the documentation implies but does not state: a host has to have at least one successful job run in the operative window to count against the entitlement, and a host that appears in the inventory but never had a job run against it is removed from the ledger before the entitled count is taken.
| Inventory source | What it reports | Drift pattern |
|---|---|---|
| Static inventory file | Hosts named explicitly in the controller. | Stale entries left in after host retirement. |
| Dynamic source plugin | Hosts pulled from a cloud or virtualization source. | Ephemeral instances counted as durable nodes. |
| Satellite inventory | RHEL estate registered through Satellite. | Hosts duplicated across multiple inventories. |
| SCM inventory | Inventory committed alongside playbook code. | Branches with overlapping host definitions. |
| External constructed | Smart inventories built from filters across sources. | Same host counted under multiple smart sets. |
Five inventory sources, one ledger.
Ansible Automation Platform reads inventory from at least five distinct source families in current platform versions, and an estate of scale typically runs more than one of them in parallel. The reconciliation has to read each source, dedupe across sources by canonical host identifier, and then attribute the surviving host count against the operating window. The deduplication step matters because a single host registered against Satellite, listed in a static inventory, and pulled into a smart inventory by filter is one managed node, not three, but the platform's raw host count number will read it as three lines.3
Static inventory files are the simplest source and the most prone to retirement drift. A host added to a static file in 2023 and decommissioned in 2024 will still sit in the file on a controller that has not been groomed, and the reconciliation has to read the static set against the actual host state rather than against the file alone. The remedy at the platform layer is inventory hygiene; the remedy at the contract layer is to remove retired hosts from the count before the count is read against entitlement.
Dynamic source plugins draw hosts from cloud accounts, virtualization sources, and identity directories. The drift pattern here is ephemeral instances counted as durable nodes. An autoscaling group that cycles instances daily will register hundreds of distinct hostnames over a year, none of which represents a persistent managed node. The reconciliation reads the operative count of unique automation targets across the window rather than the cumulative host name count, and the unique target count is materially smaller than the raw inventory pull.
Satellite inventories, SCM inventories, and externally constructed smart inventories each add their own drift modes. Satellite duplicates against static lists when the same RHEL host is registered twice. SCM inventories carry overlapping host definitions across branches that the platform reads as distinct entries. Smart inventories built on filters can pull the same host into multiple sets if the filter logic is not exclusive. All four sources have to be reconciled against a single canonical host key before the count is read.
The recurring drift patterns.
Inventory drift on Ansible Automation Platform falls into a small number of recurring patterns that the reconciliation looks for first. Reading the drift patterns explicitly produces a ledger that is materially smaller than the platform's raw host count, and in the practice the gap between the raw count and the reconciled count is the single largest source of recoverable excess on Ansible engagements.4
The first pattern is retirement lag. A host is decommissioned in the estate. The inventory is not updated. The host sits on the controller for a quarter, a year, sometimes longer, and the controller continues to report it. A reconciliation that reads the inventory against an authoritative source of truth on host state, typically a configuration management database or a hypervisor inventory, will remove the retired hosts before the count is taken.
The second pattern is environment duplication. The same logical host appears in production inventory and in a development or testing inventory under a slightly different name. The reconciliation has to read the canonical identifier and collapse the duplicates. The platform will count each entry. The order form counts the host once.
The third pattern is ephemeral inflation. Dynamic source plugins pulling from autoscaling groups, container orchestration platforms, or short lived virtual machine pools will register every instance the platform ever observed during the window. The reconciliation reads the unique automation target rather than the cumulative hostname stream. Where the cumulative stream is forty thousand and the unique automation target count is six thousand, the entitled count is closer to six thousand than to forty.
The fourth pattern is non automated inventory. Hosts appear in an inventory but the controller has never run a job against them. They were loaded as candidates for future automation, or as the residue of a discovery exercise. They do not consume entitlement under the platform definition, and the reconciliation excludes them from the count after confirming the absence of a job run record across the window.
The reconciled managed node ledger.
The output of the reconciliation is one ledger that names every host the controller observed during the operative window, classifies it by inventory source, marks its job run record across the window, deduplicates against canonical identifier, and produces a count that can be read directly against the entitled quantity on the order form. Each ledger line carries the host identifier, the source family, the job run count over the window, the duplicate flag, the inclusion verdict, and the resulting weight against the entitled count.
Where the reconciled count comes in below the entitled quantity, the recoverable excess is the share of the entitled quantity that is not consumed. That excess is what the renewal posture is built on. Where the reconciled count comes in above the entitled quantity, the exposure is the gap, and the response depends on whether a compliance inquiry has already arrived. In neither case is the ledger volunteered to Red Hat. It is the buyer's own working paper.
| Drift pattern | Frequency, last 14 engagements | Median reduction in count |
|---|---|---|
| Retirement lag | 13 of 14 | −9% to −18% |
| Environment duplication | 11 of 14 | −6% to −14% |
| Ephemeral inflation | 9 of 14 | −14% to −32% |
| Non automated inventory | 10 of 14 | −8% to −19% |
Five recurring failure modes.
Five failure modes recur on Ansible managed node reconciliations. The first is reading the controller host count as the consumption number. The controller will report every host across every inventory, deduplicated only on the host identifier the platform happens to resolve. A reconciliation that takes that number and reads it against the order form will materially overstate consumption on every estate of scale, and the buyer will enter renewal carrying a phantom commitment.
The second is skipping the job run filter. A host appears in an inventory. The controller never automated against it. The platform definition treats it as a candidate node rather than a managed node, but a reconciliation that does not read the job run history will count it as if the platform had run a hundred jobs. The job run filter is the single most important step on the reconciliation, and it is the step that most home grown reconciliations skip.
The third is conflating the window with the day. The controller will report whichever hosts are loaded the day the report runs. A reconciliation that reads a single day rather than the operative window will miss the hosts that drifted in and out, will overweight ephemeral instances that happened to be live on the report day, and will mismodel the count by the time the renewal arrives. The window is twelve months on a pre renewal reconciliation, and the trailing audit window on a compliance reconciliation.
The fourth is treating Satellite inventory as authoritative for Ansible counting. Satellite is authoritative for RHEL registration. It is one source of truth for Ansible inventory, not the source of truth. A reconciliation that reads Satellite alone will miss dynamic source plugins, smart inventories, and static files that hold hosts Satellite never saw. For the matching RHEL counting work, see counting RHEL systems accurately. For the OpenShift adjacency where Ansible automates against worker nodes, see OpenShift cores in mixed estates.
The fifth is treating the exercise as one off. Ansible inventories drift faster than RHEL host counts and OpenShift worker counts. A reconciliation completed nine months before the renewal date will already be stale by the time the quote arrives. The cadence in the practice is quarterly on estates of scale, with a deeper reconciliation in the ninety days before the renewal sits with the desk. Where the exercise surfaces material exposure, the next engagement is normally audit defense if Red Hat has already raised an inquiry, or renewal negotiation if the renewal date is the closer event. For the engagement form, see § 7 below or write the desk via the contact page.5
Notes & references
- 1. The order form on Ansible Automation Platform in 2026 names a managed node quantity at signature, and the platform reports a host count back. The two numbers are not equivalent without the reconciliation that this note sets out, and most enterprise estates see the platform host count diverge from the operating managed node count over the trailing twelve months.
- 2. The managed node definition used in this note follows the Red Hat subscription guide on Ansible Automation Platform in current form. A managed node is a host the platform automated against during the operative window. A candidate host that the platform observed but never automated against is excluded from the count.
- 3. The five inventory sources in Fig. 2.1 reflect the source families the practice sees most frequently across Ansible Automation Platform reconciliations. Smaller estates often run only one source. Estates of scale routinely run all five at the same time and benefit most from the deduplication step.
- 4. Bands referenced in Fig. 5.1 reflect the practice's observation across fourteen Ansible reconciliations closed in the trailing twelve months. They are expressed as ranges rather than point estimates and are a share of the raw controller host count, not of entitled quantity or of total Red Hat spend.
- 5. The quarterly cadence for Ansible reconciliations reflects the rate of inventory drift observed across the practice. Estates with active autoscaling, container orchestration platforms feeding the controller, or in flight acquisition activity move faster than that and warrant a compressed cadence.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.