How are "managed nodes" defined as part of the Red Hat Ansible offering?

Updated -

Red Hat Ansible Engine and Red Hat Ansible Tower are sold and supported by counting the number of "managed nodes" in the customer's environment. The following article defines what a managed node is, and what are the business rules surrounding this concept.

NOTE: The following is abstracted from official Red Hat Enterprise Agreements, specifically Appendix 1, Software Support and Subscriptions.

A "managed node" is defined as the following per Appendix 1 above:

Each Node managed by the Software. “Node” means a Virtual Node, Physical Node or other instance of software. 

This definition is broad enough to apply to all Red Hat products, but as it applies to Red Hat Ansible Engine and Red Hat Ansible Tower, managed nodes include any nodes that are indirectly managed by the software.

Examples of managed nodes that should be accounted for include (but not limited to) the following:
- Containers
- SDN, Wireless, and other Networking Controllers
- Endpoints that sit behind front-end API endpoints

A detailed example:
Red Hat Ansible Tower is running playbooks using the Cisco ACI modules, and executing tasks against any number of Cisco ACI controllers. If a single Cisco ACI controller is managing 999 Cisco Nexus switches, one must purchase enough Red Hat Ansible Tower subscriptions for the Cisco ACI controllers as well as the end devices Cisco ACI is managing. In this case, 1000 Red Hat Ansible Tower subscriptions should be purchased for support and compliance.

Comments