candidate: cloud.vmware_ops

[machacekondra]

Candidate Name

cloud.vmware_ops

Link to Github Repo

https://github.com/redhat-cop/cloud.vmware_ops

Review Due By

CHECKLIST

Business Checks:

Content Viability

• [x] must support a “business-viable” use case
• [x] isn’t just a demo
• [x] is production-ready, as in able to run in Ansible Controller “as-is”
• [x] provides a solution an end-to-end automation use case and brings value to our customers

Content Duplication

• [x] use case addressed by the content isn’t covered by another validated content collection already - to the best of our knowledge

Technical Checks:

Content Conformity

• [x] is packaged as a content collection - see the Collection Requirements Checklist
• [x] is YAML only (Exception: if plugin(s) included are necessary for this specific use-case and are not generic enough for a certified collection)
• [x] if there is a plugin(s), it is not a duplicate of something from a certified or supported collection - to the best of our knowledge
• [x] supported plugin/module used in a validated role is noted as a dependency

Content Compliance

• [x] no known policy or legal reason for why the content shouldn’t be published
• [x] README contains information about the purpose of the collection and how to install it
• [x] README contains a link to the collection license file
• [x] README contains general usage and requirements information such as required versions of ansible-core and Python, and other required libraries or SDKs
• [x] install / requirements.yml information all points to Automation Hub, not a Github repo
• [x] Repo is self-certified with the OpenSSF Best Practices and has the OpenSSF Best Practices Badge
• [x] Has 2 or more active maintainers listed in a CODEOWNERS file.
• [x] Has an approved OSI license
• [x] Content falls logically into one of these domains - infra, security, network, cloud, edge
• [x] (If internal content) Content has been or is being migrated into the redhat-cop Github org

Content Testing/Validation

• [x] runs ansible-lint “Production” profile in an active Github workflow on the repository
• [x] passes the ansible-lint “Production” profile
• [x] ansible-lint.yml file (if present) only contains justified ignores - with a comment explaining the need for each ignore

[djdanielsson]

I am wondering if we are going the wrong direction here, what if we created a collection that was about creating a VM and it would (in theory) support all the different hypervisors out there that way someone could easily use the same (or very close to) configuration to deploy a VM on any hypervisor they wanted? If we do not go that route I do think that should be the goal is to unify any other collections that create VMs to match as closely as possible.

[machacekondra]

Well, we intend to support more use cases in this collection not only VM management. We would like to for example also support:

• Installation of vsphere
• Operation visibility
• System configuration
• On going maintenance

[djdanielsson]

so I guess the question is then, should we move out the VM management side and make that a collection that is not platform specific or do we just need to ensure that any future collections that create VMs follow as similar as possible format to make it as easy as possible to use the same data across different hypervisors to create VMs

[machacekondra]

so I guess the question is then, should we move out the VM management side and make that a collection that is not platform specific or do we just need to ensure that any future collections that create VMs follow as similar as possible format to make it as easy as possible to use the same data across different hypervisors to create VMs

I see there is for exampe in azure_ops the role to manage VM Why do you think there should be platform agnostic collection to create/manage VMs? I see it wasn't considered even with other platforms.

[bardielle]

@djdanielsson thank you for taking a look on our validated content collection.

I think that "abstract role" as you @djdanielsson suggested will be really complicated since each infrastructure has different variables and use cases coverage. Also, the dependencies will be much bigger than you really need for one infrastructure.

[djdanielsson]

I think we have come up with a plan for all this, and we just need a couple people to review the code base here.

[alisonlhart]

@arnav3000 @ericzolf @sean-m-sullivan Any thoughts on this candidate? We're going to vote for approval tomorrow in the ACoP call.

[sean-m-sullivan]

I've reviewed and it looks good, voting for approval, I will not be able to make it to the meeting.

[alisonlhart]

Approved by the ACop! Feel free to release to Automation Hub at your discretion.

[bardielle]

Thanks a lot @alisonlhart, @sean-m-sullivan and the team