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 (no surprises considering Vmware along with others proposed it). From looking at the specification, I’ve found it to be quite comprehensive and extensible for forming an infrastructure model that you can request to be provisioned. Now there are some weaknesses (I made some note of this here [1] and Lori MacVittie[2] had some stronger opinions) but I believe there is an OVF2.0 spec in draft. Certainly sounds like they’re using the semantics of REST and using OVF as the XML schema as the body of requests. The nouns will be quite aligned to the Sun Cloud API but with their (VMware) model based on a standardised DMTF schema. Their “VApp” is most likely a VirtualSystem and their “VDCs” & “Organizations” are represented by VirtualSystemCollections in various configurations. What would be interesting to know (but so much to this mailing lists goals) is what schemas they use to pass about on the message bus. On another note, I looked through Abiquo [3] code yesterday and found it to be chock-a-block with DMTF schemas, OVF being one. Andy. [1] http://sla-at-soi.eu/?p=403 [2] http://www.infra20.com/post.cfm/ovf-a-few-layers-short-of-a-full-stack [3] http://www.abiquo.com From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: 25 April 2009 15:49 To: Alexis Richardson Cc: occi-wg@ogf.org Subject: Re: [occi-wg] vCloud architecture diagrams This is (unsurprisingly) really raising the bar. FWIW I'm not one of the people who's seen the API so it's interesting to see they too went for OVF over a REST based API... it seems that OVF is in fact at the heart of this protocol (or is it vice versa?). That may or may not be a good thing. Object model looks like this (courtesy pp59): * Organisation * Virtual Data Center (VDC) * vApp (multiple VMs, "internal" network, n-tier app in a box) Other observations: * Flexible networking (like ours) - multiple tagged networks ("foo", "bar", "VDCnet", "Public", "Private") * Persistent VMs (we want to allow for both) * SLA on vApp (to be implemented as an extension) * Overprovisioning (interesting area, from user PoV means hiding size of storage pools, etc. which most providers will want to do anyway) * Both serialization and configuration via OVF * Talk about scaling to 10k hosts and 100k VMs * "HTTP based resource oriented interface" (just like OCCI!) * "All the characteristics of the WWW • Extensible without breaking client. (like OCCI) • Client only has to know about what it cares about. (like OCCI) • Can route, proxy, cache <- interesting, useful, can be difficult to achieve * Interestingly uses Spring Framework<http://en.wikipedia.org/wiki/Spring_Framework> * Injects dependencies and wires together Spring beans * Forces programmer into maintainable design pattern; isolates dependencies * OSGI: Standard dynamic module framework (Global registry of interfaces to instances - Dynamically load, unload, start, stop bundle)... not sure how interesting this is really * JMS publish/subscribe messaging bus isolates end points (message buses will be a key component of most successful cloud architectures IMO - something to consider when we're talking about formatting) * Hibernate simplifies DB code & DB independence The actual VMware architecture (pp76) I found less interesting because it varies from provider to provider and is the detail that the cloud conceals from end users. Sam On Sat, Apr 25, 2009 at 9:49 AM, Alexis Richardson <alexis.richardson@gmail.com<mailto:alexis.richardson@gmail.com>> wrote: Wes, Thanks for that. Some of us have seen vCloud APIs under NDA. There is definitely overlap with OCCI. VMware are aware of OCCI and I personally hope we see them contribute at some stage. alexis On Fri, Apr 24, 2009 at 11:06 PM, Wes Felter <wesley@felter.org<mailto:wesley@felter.org>> wrote:
VMware has revealed few technical details about vCloud, but I found this public presentation containing some interesting diagrams starting on pages 50 and 76. Overall, the concepts appear similar to the work going on in OCCI.
http://forum.stanford.edu/events/2009Plenary/Orran%20Kriegar.pdf
The bullets "Researchers can replace any part of the service." and "Researchers can replace the entire implementation and clone the API" also caught my eye.
Wes Felter - wesley@felter.org<mailto:wesley@felter.org> _______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@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.