Need to understand a little bit more on this.
a)
Wouldn’t it be better to add the missing attributes/elements
to OVF than inventing a new format
b)
The client has to understand something – either OVF or
some other representation. So why not add to OVF ?
c)
Finally, are there something fundamentally missing from/totally
incompatible with OVF that it cannot be fixed ?
Cheers
<k/>
From:
occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam
Johnston
Sent: Thursday, June 18, 2009 4:20 AM
To: Randy Bias
Cc: occi-wg@ogf.org
Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@neotactics.com> wrote:
Sure, but that's not the issue. The issue is VM portability. It's important, but difficult. That's my point. Specifying the hypervisor of an image just means the cloud has enough foreknowledge to reject the upload.
Exactly. In fact my main concern is that as OVF is only ever used as a
transport rather than run-time format there are two potentially lossy
transformations (one to bundle up e.g. a VMware virtual machine to OVF and
another to unbundle it to say Hyper-V). Any settings that fall outside of the
OVF net (potentially including critical details such as interface parameters)
will be ignored at best and lost at worst.
If a client wants to make a VM it should not need to understand OVF so we will
have our own, simple descriptor language that I imagine will end up looking
like the stuff in VMX files (example attached). If we are careful about how we
do this we may well be able to solve the VM portability problem as well -
something I'm sure many of the open source projects would be happy to see.
Sam