What Level of Support do I Receive for the Included Red Hat Ansible Engine Modules?

Updated -

Installing Red Hat Ansible Engine currently includes a large number of modules that are classified into four different categories.

While we endeavor to provide the best customer service experience in every support interaction, the level of support will vary between each of the module categories. The following are some example scenarios to delineate what that may look like through the course of a ticket:

Scenario 1: Core Module
Problem Statement: Yum module throws an error when validate_certs is passed.
Items Needed for Investigation:

  • The ansible engine version affected
  • The relevant task
  • The corresponding error output from the ansible-playbook execution

Example workflow:

  • The case owner will attempt to replicate the reported issue against the same reported Ansible Engine version.
  • If they are able to replicate and the behavior reported is determined to be a bug and there is not an existing bug open, the case owner will file a new bug on the customer's behalf at the Ansible GitHub repo.
  • As the Ansible engineering team maintains the core modules, they will prioritize the issue and work towards identifying a fix.
  • In the event that there is already an existing bug, the case owner will provide details to the customer around an expected fix release version.
  • In the case of either a new or existing bug, the case owner will investigate potential workarounds to the reported issue.

Scenario 2: Network Module
Problem Statement: Failure to connect to specific network devices when using ios_config module.
Items Needed for Investigation:

  • The Ansible Engine version affected
  • The full playbook file with relevant provider section
  • The corresponding error output from the ansible-playbook execution

Example workflow:

  • The case owner will attempt to replicate the reported issue against the same reported Ansible Engine version.
  • If they are able to replicate and the behavior reported is determined to be a bug and there is not an existing bug open, the case owner will file a new bug on the customer's behalf at the Ansible GitHub repo.
  • As the Ansible Network team maintains the Network modules, they will prioritize the issue and work towards identifying a fix.
  • In the event that there is already an existing bug, the case owner will provide details to the customer around an expected fix release version.
  • In the case of either a new or existing bug, the case owner will investigate potential workarounds to the reported issue.

Note: Minimum Viable Platform Agnostic (MVPA) modules are a set of networking modules (net_*) that allow playbook runs against different device types. In the event that a customer is targeting a device that is not supported under the scope of the Networking add-on, we reserve the right to provide support that is commercially reasonable.

Scenario 3: Certified Module (Coming Soon)
The following scenario is still in progress, and will be announced soon. Until then, certified modules are considered as community modules until further notice.

Scenario 4: Community Module
Problem Statement: Jira module throws an error trying to create a new issue
Items Needed for Investigation:

  • The Ansible Engine version affected
  • The relevant task
  • The corresponding error output from the ansible-playbook execution

Example workflow:

  • Community modules are maintained by community contributors and are not supported under an Ansible engine subscription.
  • In the event, however, that a customer is experiencing an issue with a community module, we reserve the right to provide commercially reasonable support. Expected release fix dates or workarounds may not necessarily be included.

For more information on Ansible Engine Scope of Coverage, please refer the following article.