search

glennmatthews / cot

Common OVF Tool
MIT License
92 stars 23 forks source link

COT considers OVF with different CPU InstanceID across different profiles as invalid #68

Open howardjones opened 7 years ago

howardjones commented 7 years ago

I've just spent a few days writing a similar tool to cot (which I just found, d'oh!), to feed packer output into, as part of an automated build process. My tool also adds properties and DeploymentOptions, to have small/medium/large deploys from one OVA. This is working fine with ovftool.

However, if I say cot info my-appliance.ova I get

LookupError: Found multiple matching 'cpu' Items (instances ['11', '13', '15', '17', '19', '21'])

Which is true, but each of those has a different configuration attribute, which again, is correctly picked up by ovftool. Any ideas what could cause this? I based my changes on the VMware VCSA OVA file, which uses ovf: as a default namespace, whereas cot-generated ovf files explicitly namespace everything...

glennmatthews commented 7 years ago

Hm, this is not a use case I've previously encountered. I can look into it (could you provide an OVF file?) but I'm curious, is there a reason you're using a different InstanceID for different configurations, instead of using the same InstanceID for each config-specific CPU item?

howardjones commented 7 years ago

Because according to the OVF spec, section 8.3: 

InstanceID A unique instance ID of the element within the section.

Although, looking back at the VCSA .ovf, that does re-use the InstanceID too. I don't see anything in either the VirtualHardwareSection or DeploymentOptionSection parts of the docs that actually says you can though :-)

I've attached an example OVF also.

tmp.ovf.txt

glennmatthews commented 7 years ago

Thanks!

You want section 9.8 (DeploymentOptionSection):

  • Each Item has an optional ovf:configuration attribute, containing a list of configurations separated by a single space character. If not specified, the item shall be selected for any configuration. If specified, the item shall be selected only if the chosen configuration ID is in the list. A configuration attribute shall not contain an ID that is not specified in the DeploymentOptionSection.
  • Within a single VirtualHardwareSection or ResourceAllocationSection, multiple Item elements are allowed to refer to the same InstanceID. A single combined Item for the given InstanceID shall be constructed by picking up the child elements of each Item element, with child elements of a former Item element in the OVF descriptor not being picked up if there is a like-named child element in a latter Item element. Any attributes specified on child elements of Item elements that are not picked up that way, are not part of the combined Item element.

That said, your approach is also valid (if less common in my own experience), so I will keep looking into this issue :smile:

Thanks!

howardjones commented 7 years ago

Aaah. OK. I'll switch over then. There's no need to make life harder :-)

If I could get cot to add disks with no images, I think I could ditch my own work altogether, then.

glennmatthews commented 7 years ago

"Disks with no images" - as in Disk elements with no associated fileRef? COT recognizes these as valid but I don't currently have support for creating them. Wouldn't be hard to add though I think. If that's not what you're looking for, please clarify.

howardjones commented 7 years ago

yes - A type 17 \<Item> and a \<Disk> with a capacity but no fileRef or populatedSize, so it shows up as an unformatted block device in the final VM. I think a few things use this kind of arrangement for log or database partitions where the sizing is different depending on the deployment option chosen. In my use case, the extra disks only exist in some of the configurations.