[occi-wg] vCloud architecture diagrams

[Krishna Sankar (ksankar)]

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