Ansible Certified Content FAQ

The following is a Frequently Asked Questions for the Ansible Automation Platform Certification Program. If you have any questions regarding the items below, please email ansiblepartners@redhat.com.

Why certify Ansible collections?

The following reasons:

1. The Ansible Certification Program enables a shared statement of support for certified Ansible collections between Red Hat and the ecosystem partner. An end customer may open a support ticket (request for information, a problem, etc.) with Red Hat and expect the ticket will be addressed by Red Hat and the partner ISV that provided the content.

2. Red Hat offers go-to-market benefits for certified partners to grow market awareness, demand generation and collaborative selling.

3. Ansible certified collections are distributed via Ansible Automation Hub (subscription required), a centralized repository for jointly supported Ansible Content. As a certified partner, publishing collections to Ansible Automation Hub provides end customers the power to manage how trusted automation content is used in their production environment with a well known support life cycle.

For more information about getting started with certifying a solution, please refer to https://www.ansible.com/partners for details.

How do I get a Collection certified?

Please refer to our Software Certification page for the Ansible Certification Policy Guide and Ansible Certification Workflow Guide.

What’s the difference between Ansible Galaxy and Ansible Automation Hub?

Collections published to Ansible Galaxy are the latest content published by the Ansible community and have no joint support claims associated. Ansible Galaxy is the recommended front-end “directory” for Ansible community content.

Collections published to Automation Hub are available to joint customers of Red Hat and partners. Customers need an Ansible subscription to access and download certified collections present on Automation Hub. A certified collection means that Red Hat and partners have a strategic relationship in place and are ready to support joint customers, and may have had additional testing and validation done against them.

How do I request a namespace on Galaxy?

Please send an email to ansiblepartners@redhat.com after you request a namespace via an Ansible Galaxy GitHub Issue. You, and any other admins, will need to log into Galaxy at least once before making this request. Once users are added as admins of the namespace, they can add other admins for the namespace.

Are there any restrictions for Galaxy namespace naming?

Collection namespaces must follow python module name conventions. This means collections should have short, all lowercase names. Underscores may be used in the collection name if it improves readability.

Are there any naming recommendations for Collection naming?

A general suggestion is to create a collection with company_name.product format. This way multiple products may have different collections under the company namespace.

How do I get a namespace on Ansible Automation Hub?

Email the Ansible Partner Engineering Team at ansiblepartners@redhat.com. We recommend using the same namespace on both Ansible Galaxy and Ansible Automation Hub.

Does Galaxy house the source code for my Collection?

No, the collection source code must be managed outside of Ansible Galaxy in a public source control tool, such as GitHub. Ansible Galaxy only contains collection artifacts for distribution. The source must be linked in the collection’s galaxy.yml file, which will populate a link on the collection page on Galaxy.

Does Red Hat officially support Collections downloaded and installed from Ansible Galaxy?

No, collections downloaded from Galaxy are 100% community supported. Users and contributors to any such collection must contact the collection developers directly.

How does the joint support agreement on certified collections work?

If a customer raises an issue with the Red Hat support team on a certified collection, Red Hat support will triage the issue. They will check if the problem exists within Ansible or Ansible usage, and they will also check if the issue is with the certified collection. If it is a collection-specific problem, support teams will transfer the issue to the certified collection’s owner through TSANet. See more information on TSANet and Red Hat support here.

How to migrate existing modules/plugins to collections?

This guide outlines collection development. To test if the collection is working properly, follow the usage guide found here.

Can we create and certify a collection containing only Ansible Roles?

Collections containing only roles may be created and certified.

Can a certified collection have a dependency on a community collection?

No, certified collections can only depend on other certified content. Certified collections cannot depend on community collections, like community.general.

Are there licensing requirements for a certified collection?

A collection can use any OSI approved license. To avoid ansible-test sanity errors related to not using the GPLv3 license, you can ignore those tests in your sanity ignore files. GPLv3-or-later is not required for certification.

What are the update and product support requirements for a certified collection?

A certified collection must be tested on and support at least two versions of Ansible that are tied to supported versions of Ansible Automation Platform. Refer to the Red Hat Ansible Automation Platform Life Cycle for information on currently supported versions. Certified collections that do not meet this requirement and are not updated in a timely manner are subject to deprecation and removal from the certified catalog.

What is the difference between Validated Content and Certified Content?

Ansible validated content collections contain pre-built YAML content (such as playbooks or roles) to address the most common automation use cases. It takes a primarily platform-agnostic approach to collection content, and focuses on domains like networking, security, etc. Certified content is typically built to serve a specific platform or product, and can contain actual code in the form of modules and/or plugins in addition to YAML content.

Unlike certified content, validated content is not subject to any support requirements. This is because validated content focuses on customization and is designed so customers can modify the content to serve their needs. Any issues with validated content should be filed directly at the source repository for that collection, rather than through TSANet.

What are the testing/linter requirements in the certification test pipeline?

All requirements, rules, and tests with each component below must be met in each certified release unless otherwise specified. These requirements are subject to change with notice from the Ansible Partner Engineering team.

Additional requirements around documentation and policy are outlined in the Ansible Certification Workflow Guide, located here.

Should I test my certified collection with the Ansible development branch?

We recommend all partners include the Ansible devel branch in CI testing in addition to Ansible versions they support. Devel testing brings awareness to upcoming Ansible releases and changes.

How do I run sanity tests on my collection?

Ansible Sanity tests are made up of scripts and tools used to perform static code analysis. The primary purpose of these tests is to enforce Ansible coding standards and requirements. Ansible Collections must be in a very specific path, such as the following:
{...}/ansible_collections/{namespace}/{collection}/

You must ensure your collection is in that specific path—with an empty directory named ansible_collections, then a directory for the namespace, and finally a directory for the collection itself.