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?

You may certify Ansible collections for 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. When opening a case with Red Hat regarding an issue that involves both Red Hat and an Ecosystem Partner, a customer may be asked to open a ticket with the Ecosystem Partner for additional support and collaboration through TSANet. For more information, consult the "Collaboration between partners" section of Best practices for engaging with Red Hat Support.

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, see Red Hat Ansible Automation Certification.

How do I certify a collection?

Visit the Software Certification page for more information on 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 with limited testing and no required verification.

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, 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?

You must use an Ansible Galaxy GitHub issue to request a namespace. Each admin 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 to 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. For more information, please see Creating a new collection.

Are there any naming recommendations for collection naming?

A general suggestion is to create a collection using the company_name.product format. Using this format enables multiple products to have different collections under the company namespace.

How do I get a namespace on Ansible Automation Hub?

After completing each step from the Ansible certification workflow guide, email the Ansible Partner Engineering Team at ansiblepartners@redhat.com to request your namespace. 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 fully community maintained. 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 the problem falls in this category, Red Hat support solves the issue without involving the partner, which significantly reduces the load on the partner technical support.
If it is a collection-specific problem, support teams will transfer the issue to the certified collection’s owner through TSANet. For more information on TSANet and Red Hat support, see TSANet Membership.

How do I migrate existing modules and plugins to collections?

For guidance on turning your individual modules and plugins into a collection, see Developing collections.

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

Collections containing only roles should be submitted as validated content. For more information, see the Ansible validation workflow guide.

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 must use an 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. For more information, see ignores.

NOTE: 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-core 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 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 that 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 and 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.

NOTE: For information on EDA testing, see EDA Partner Testing Templates.

Additional requirements around documentation and policy are outlined in the Ansible certification workflow guide.

Should I test my certified collection with the ansible-core devel branch?

We recommend all partners include the ansible-core devel branch in CI testing in addition to ansible-core versions they support. Devel testing brings awareness to upcoming Ansible releases and changes. We also recommend all partners watch the news-for-maintainers tag in the Ansible Forum for important updates for all collection maintainers.

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. For more information, see Sanity tests.

We also highly recommend having unit and integration testing for certified collections to ensure code stability and resilience to bugs.

Additional resources
- Sanity tests
- Testing Ansible and Collections
- Testing collections

Running sanity tests in your collection repository

Use the following procedure to use GitHub Actions to run sanity tests in your collection repository:

Procedure

1. Navigate to the collection template workflows on GitHub.
2. Copy the workflow template file to the .github/workflows directory of your collection repository. Read the comments in the file.
3. Remove extra actions (for example, unit- and integration-tests-related sections) and update the ansible-core versions to be tested against. Create and merge a pull request that adds the file to your repository.
4. Enable the workflow on the Actions tab in the repository.

After completing this procedure, sanity tests will run automatically in new pull requests.

If your repository is not on GitHub or you don’t want to use GitHub actions, other CI tools, such as Azure Pipelines, are available on the market.