[occi-wg] vCloud architecture diagrams

[Krishna Sankar (ksankar)]

Thanks.

a)	While not a full-fledged DMTF person, I am monitoring and attending conf calls as much as possible. I am sure there are other folks also.
b)	We should contribute to OVF. I think it is good to leverage existing mechanisms as much as possible and extend them. OVF 1.1 work is happening.
c)	Yep, the Cloud Incubator is interesting. Need to see what comes out of it. It will take some time to go through the form-norm-storm stages and then get to the perform stage. Lot of big players. I plan to participate.

Cheers
<k/>

|-----Original Message-----
|From: Edmonds, AndrewX [mailto:andrewx.edmonds at intel.com]
|Sent: Monday, April 27, 2009 1:48 PM
|To: Krishna Sankar (ksankar); Tim Bray
|Cc: occi-wg at ogf.org
|Subject: RE: [occi-wg] vCloud architecture diagrams
|
|Great points Krishna!
|I would say that if we had a DMTF person here (do we?), they might say
|that other related DMTF activities out of the VMAN initiative would most
|likely cover points i) and ii). Like you say "best as a packaging-and-
|installation-mechanism". The remainder, if fleshed out, could be perhaps
|contributions from this group to the specification. On DMTF seems like
|they're mobilising their muscle [1]...
|
|Andy
|
|[1] http://www.dmtf.org/about/cloud-incubator
|
|-----Original Message-----
|From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com]
|Sent: 26 April 2009 17:42
|To: Tim Bray; Edmonds, AndrewX
|Cc: occi-wg at ogf.org
|Subject: RE: [occi-wg] vCloud architecture diagrams
|
|Tim, Couple of points:
|
|i)      Yep, OVF is at its best as a
|packaging-and-installation-mechanism than a
|transfer-state-across-arbitrary-platform mechanism.
|ii)     In the Develop-Configure-RunTime continuum, OVF is effective in
|the develop-configure stages, especially during the configure stage
|across ownership boundaries.
|iii)    As Lori mentions, another dimension is the transfer of network
|context which is difficult
|iv)     Even extension of context - for example 3 web servers behind one
|load balancer in the enterprise and then cloudbursting to an SP for
|fourth web server - load balanced by the same device - is not automatic.
|
|But In defense of OVF, it does a few things good enough.
|
|a)      It works well for P2V/V2P, backup, archival and similar
|functions
|b)      Packaging multi-tier applications, across ownership domains,
|including stating the relationships between the software components that
|makeup the tiers, is doable with OVF (and with a few extensions ;o)).
|Granted, the rich expressiveness for encapsulating the network context
|is not complete, but the application layer, including the hardware
|specification, works.
|c)      The metadata, in the envelope schema is decent
|d)      The general mechanics for packaging files (including
|compression, digest et al) is workable
|e)      In an IaaS world, the OVF eco-system can achieve running
|"arbitrary OVF" - (of course with the binary platform compatibility
|caveat ;o))
|f)      And VMotion is plausible and even when limited to local LAN; and
|is useful for tasks like maintenance, version upgrade, patching and so
|forth
|g)      The DMTF group is just starting the plugfest - first one
|sometime in June. In due time, features will get added ( and, as you
|mention, in sync with the state of the art)
|h)      Talking about the state of the art in the live-migration
|(life-migration as the RESERVOIR folks call it ;o)), even in the JVM
|world, migration across different JVMs is not that easy.
|i)      The OVF 1.1 work is happening and this would be a good time to
|influence the specification. Folks like SLA at SOI should suggest elements
|that need to be incorporated into OVF - the "non-functional elements" as
|they put it
|j)      IMHO, OVF is the closest we have in terms of expressive metadata
|and packaging format. Of course, interfaces and API is another matter.
|k)      Going back to Lori's excellent blog, no doubt the network
|context is the Achilles heel. The expression, rendering and overlaying
|the network context required by a migrating VM over an existing network
|substrate is still an art - mostly done by manual admins. This limits
|the functionality offered by the Cloud Providers.
|Cheers
|<k/>
|
||-----Original Message-----
||From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On
|Behalf
||Of Tim Bray
||Sent: Saturday, April 25, 2009 11:16 PM
||To: Edmonds, AndrewX
||Cc: occi-wg at ogf.org
||Subject: Re: [occi-wg] vCloud architecture diagrams
||
||On Apr 25, 2009, at 10:42 AM, Edmonds, AndrewX wrote:
||
||> I think one of the big things within presentation is the usage of
||> OVF and its status as a "1st class citizen" in their API
||
||I've been looking at OVF.  There's a lot to like there, but the
||thought of using it for *interop* is awfully scary.  The notion of
||exposing various aspects of machine state or maybe even machine-group
||state in OVF seems plausible, but in the general case, importing OVF
||that someone else has produced and attempting to reproduce what it's
||describing, in an automated way, seems beyond the current state of the
||art.
||
||I'd be unsurprised and pleased to be told "Everybody knows that,
||silly".  I'd be surprised and delighted if someone put up their hand
||and said "Oh yes, we can do that for arbitrary OVF".  Or possibly I'm
||just missing something obvious.
||
||  -Tim
||
||_______________________________________________
||occi-wg mailing list
||occi-wg at ogf.org
||http://www.ogf.org/mailman/listinfo/occi-wg
|-------------------------------------------------------------
|Intel Ireland Limited (Branch)
|Collinstown Industrial Park, Leixlip, County Kildare, Ireland
|Registered Number: E902934
|
|This e-mail and any attachments may contain confidential material for
|the sole use of the intended recipient(s). Any review or distribution
|by others is strictly prohibited. If you are not the intended
|recipient, please contact the sender and delete all copies.