Hello all, 
in the last few days I watched two Expert Extras by Roger Lopez [@Lopez] on Red Hat Learning Subscription, one of them was Automate VMware VM Provisioning in Minutes with Ansible. I saw how a collection called vmware_ops from Red Hat was used and found this collection in the Community of Practice. One of the contributors is Mike Morency [@mikemorency]. And now I have a question about something I didn’t really understand: How does this collection differ from vmware.vmware, vmware.vmware_rest, and community.vmware? Should it be seen as a supplement, an improvement, or a competitor?
Thanks for information and hints.
Best regards
Stefan
Someone may come and correct me, but I can at least help some. RedHat’s AAP/Ansible enterprise support entitles customers to three tiers of Ansible content support.
The first is community or “unsupported” content. RedHat does not directly support these projects, meaning if you opened a RedHat support case for an issue you would probably get a limited response. You can still open GitHub issues, or ask for help in the forums, or get help from a third party.
Unsupported collections are still important to RedHat and obviously Ansible as a whole. If you are a customer, you should still feel OK opening a support ticket for issues. Its possible your account manager has a suggestion, and at the very least it shows RedHat that their customers are interested in an unsupported feature. Unsupported collections are available through galaxy.ansible.com. Anyone can upload a collection there.
The second is certified content. Collections should state if they are certified in their README. The certification process involves working with the RedHat Ansible partner team to meet certain support and quality standards. Additionally, certified collections tend to focus on modules and plugins.
Once your collection is certified, it can be uploaded to Automation Hub and galaxy.ansible.com. Automation hub is a special version of galaxy that only allows for approved (by RedHat) uploads. Since these collections go through a more rigorous process to be available, RedHat will offer support for issues in these collections.
If you are a customer, the best way to raise issues is through your account manager or support portal. This allows RedHat to connect the issue with a customer, and prioritize it.
Non-customers can still use the certified collections. However, they are limitted to community support and GitHub issues which may not be a high priority.
The third is verified content. Verified collections have RedHat support, but focus more on practical applications of Ansible via roles and playbooks. (This is my opinion/experience) The verified content is meant to be more of a guide or working example. Although you can use the content directly, I think some people would find it beneficial to use that as a starting point for something more custom.
Verified content is similar to certified content, in that it is only available on Automation Hub or directly from Github. Only customers are entitled to support
Community tends to be (maybe is always) unsupported. Collections in the COP space tend to be verified content.
For vmware specifically, all of the collections work together (more or less) and offer different levels of support. As a maintainer of vmware.vmware and vmware.vmware_rest, I like to think that I have a good relationship with the maintainer of community.vmware (@mariolenz) and they are involved in the certified collections as well. We try to avoid redundant functionality. When something is added to the certified content, we try to deprecate it in the community content.
community.vmware - community supported
vmware.vmware - certified content
vmware.vmware_rest - certified content
cloud.vmware_ops - verified content
1 Like
Yes, I also think do 
1 Like
Hello Mike [@mikemorency],
thank you very much for your detailed explanation. This helps me to better understand how to assessed the different collections in combination.
Best regards
Stefan