It seems we might switch to vCloud as well. Since I'm new to vCloud, it would be helpful to at least get some general idea what's what. Please correct me where I'm wrong.

• A VM is always part of a vApp.
• A vApp is a collection of one or more VMs
• vCloud can manage your IPs for you and be the DHCP server

To create a VM, you could do bare metal provisioning but I think there's also some image management using vApps. I'm having a hard time finding information (as always with VMware), so any additional information would be helpful.

I have fog 1.18 up and running on a CentOS 6 box using the ruby193 software collection. I've been experimenting with it from the command line, but haven't been able to instantiate anything smaller than a vApp. Inspecting

VcloudDirector.organizations.first.catalogs.first.catalog_items.first

Looking at https://github.com/fog/fog/blob/master/lib/fog/vcloud_director/README.md, it may be easier to just support vCloud as an image-based compute resource. I think a vApp. That said, I think you only want to support vApps with a single VM to map properly to the foreman model.

This would be almost hackish but would work for single-vm apps. It would be interesting to map an application definition to a 'vapp' equivalent in Foreman. We currently use 30+ different app/db servers (each with its own hostgroup/puppet classes/etc) and this constitutes a single application in line with what VMware calls a vapp. They are logically separated by a parent hostgroup. For us adding a VM to a 'vapp' means adding a new VM to a 'hostgroup' parent or parent's child (i.e. if we add a new cluster member to a 'prd/cluster' child it means adding a new vm to vapp 'prd'.

I don't know if this model can be extended onto a vapp via fog (or if any of the other compute resources have a similar definition on a application group like a vapp) or if this is even a feature that would be in line with what Foreman is trying to accomplish.