[occi-wg] Opinion Poll: IaaS or PaaS ?

Sun Jun 21 06:12:40 CDT 2009

Krishna,

Native OVF support would certainly be advantageous to OEM offerings
including Cisco's Unified Cloud (per Cisco and VMware Enhance Virtualization
with Powerful, Scalable Unified Computing
System<http://www.vmware.com/company/news/releases/cisco-vmw-oem.html>)
and IBM 's WebSphere CloudBurst Appliance (per IBM CloudBurst runs on
ESXi<http://blogs.vmware.com/esxi/2009/06/ibm-cloudburst-runs-on-esxi.html>)
as these products are based on VMware, which as of the latest release now
has full support for
OVF<http://www.dmtf.org/about/cloud-incubator/Cloud_Incubator_Quote_Sheet.pdf>(presumably
meaning as a run-time rather than interchange format). As such
we will ensure that it is supported, in that implementations that choose to
implement it can both accept and produce OVF representations. Whether we
make it an absolute requirement by incorporating it into the OCCI standard
is yet to be decided - I'm unconvinced.

Following ElasticHosts' example all you would need to create a server is the
following (bearing in mind we're currently talking about putting storage and
network association metadata in the headers):

$ cat << EOF | curl --url http://example.com -d @-
name TestServer
cpu 2000
mem 1024
EOF

Doing the same in OVF would require (at least) tens of lines of XML, and
were it easy to generate we wouldn't be seeing questions like "How do you
use completely free software to create ovf files for VMware
ESXi?<http://stackoverflow.com/questions/681519/how-do-you-use-completely-free-software-to-create-ovf-files-for-vmware-esxi>"
essentially going unanswered.

Don't get me wrong - OVF support makes a lot of sense for many use cases...
tor example it would be cool to be able to create a VM in a tool like VMware
Fusion and upload it directly (save for the ironic lack of OVF
support<http://communities.vmware.com/message/947976>)
and public cloud providers I'm sure would be very happy to make it easy for
enterprises to upload existing virtualised infrastructure. Making it an
absolute requirement is another matter (and one that made a lot more sense
with my earlier proposals whereby it would have been carried transparently
in Atom's content element).

As for my second guessing what other SSOs are up to, these are my opinions
based on clues like VMware's recent
announcement<http://www.vmware.com/company/news/releases/cloud-initiatives-vmworld.html>that
"
*as one of the original authors of the Open Virtualization Format (OVF)
standard now released from the Distributed Management Task Force (DMTF),
VMware will build upon that work by submitting a draft of its VMware vCloud
API*". As they say in French, "les cheins ne font pas des chats" (literally
"cats don't make dogs") so with an existing standard injected this early in
the development process it's hard to imagine the result won't look like (if
not be [almost] identical to) the VMware
API<http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/index.html>,
complete with its 87 Managed Object References, 1331 Data Object Types, 168
Enumeration Types and 435 Fault Types.

Of course Cisco's a DMTF member so you've got a better chance of verifying
this than I do... I've not yet been able to justify coughing up $200 for
early access to the docs (assuming they already exist).

Sam

On Sat, Jun 20, 2009 at 8:11 PM, Krishna Sankar (ksankar) <ksankar at cisco.com
> wrote:

>  Sam,
>
> a)      I suggest you tone down your rhetoric (unless you have proof that,
> that is so) on what other SDOs might be doing … seek to understand first ;o)
> OGF (and GGF) has  long history of working with others and we do not want to
> singlehandedly reverse that
>
> b)      This is the standard NIH syndrome
>
> c)       And simpler format usually will get complex as the domain
> matures.
>
> d)      Moreover we can leverage future work done by others as the cloud
> computing domain grows and by extension we get more demands for the OCCI
> interfaces feature set …
>
> e)      BTW, why is it difficult to roll an OVF file ? After all it is an
> XML file. Are you having second thoughts on XML format ? ;o) Time to come
> clean if that is the case !
>
>
>
> Cheers
>
> <k/>
>
>
>
> *From:* Sam Johnston [mailto:samj at samj.net]
> *Sent:* Saturday, June 20, 2009 10:21 AM
> *To:* Michael Behrens
> *Cc:* Krishna Sankar (ksankar); Randy Bias; occi-wg at ogf.org
>
> *Subject:* Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
>
>
>
> I'd be surprised if OASIS were working on a new version given it's a DMTF
> standard but you're right - it's extensible and it's certainly one format I
> expect most, if not all, implementations to support anyway. DMTF are no
> doubt very busy rubber stamping VMware's vcloud API at the moment so I doubt
> OVF is high on their list of priorities - waiting for news from Thijs
> regarding our collaboration with them.
>
> The question then is if we want/need a simpler format ala ElasticHosts:
>
> cores 2
> memory 2048
> ...
>
> We quite probably do (it is after all a fairly simple problem to solve, as
> evidenced by the simplicity of your average virtual machine descriptor), and
> there are a good few people in support of this. In any case it would be at
> least mildly ironic to raise hell over XML in the protocol only to require
> it for the data interchange format ;)
>
> Rolling your own OVF file is a bit of a mission compared to sending a few
> key value pairs...
>
> Sam
>
> On Sat, Jun 20, 2009 at 6:27 PM, Michael Behrens <michael.behrens at r2ad.com>
> wrote:
>
> The OVF standard is extensible, so perhaps start with that and then extend
> as needed.  Does anyone know if OASIS is working on a new version?  If so,
> then perhaps a runtime/creation use-case could be submitted.
>
> Krishna Sankar (ksankar) wrote:
>
> 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 at ogf.org [mailto:occi-wg-bounces at ogf.org<occi-wg-bounces at ogf.org>]
> *On Behalf Of *Sam Johnston
> *Sent:* Thursday, June 18, 2009 4:20 AM
> *To:* Randy Bias
> *Cc:* occi-wg at ogf.org
> *Subject:* Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
>
>
>
> On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb at 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
>
>
>     On Jun 14, 2009, at 8:38 PM, Sam Johnston wrote:
>
>
>
> On Mon, Jun 15, 2009 at 5:05 AM, Randy Bias <randyb at neotactics.com> wrote:
>
>    If you don't have this capability then allowing the upload of completely
> opaque images and hoping they will have any kind of reasonable performance
> on an arbitrary cloud providers system is a pipe dream.  This is an area
> badly in need of standardization, but I doubt it will come any time soon.
>
>
> Fortunately specifying the type of hypervisor an image is tied to/optimised
> for isn't hard...
>
> Sam
>
>
>
>
> Randy Bias, Cloud Strategist
> +1 (415) 939-8507 [m], randyb at neotactics.com
>
> BLOG: http://cloudscaling.com
>
>
>
>
>
> ------------------------------
>
>
>
> _______________________________________________
>
> occi-wg mailing list
>
> occi-wg at ogf.org
>
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090621/b2a3d900/attachment.html 