vCloud architecture diagrams
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
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> 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 _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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> 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> 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 _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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.
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
I have not looked at it in detail, but would be surprised if it could be used for true interop any time soon. More likely we'll need a way to either pre-parse and reject OVFs that aren't viable on a given platform or a way to convert on import. Or some combination. --Randy On 4/25/09 11:15 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote:
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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Randy Bias, VP Technology Strategy, GoGrid randyb@gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias
On Sun, Apr 26, 2009 at 8:15 AM, Tim Bray <Tim.Bray@sun.com> wrote:
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.
My original designs (I've been working on this problem since well before OCCI was conceived) had OVF embedded in Atom's content element. The intention was that it (and its eventual equivalents for storage and networking resources) be opaque except perhaps for a small but hopefully growing number of directives. Of course flat legacy formats (VMware's VMX for example) could be carried as CDATA as well and the number of Internet media (MIME) types the implementation supported would be a key differentiator/area of innovation. I've developed XSLT stylesheets to downconvert to ElasticHosts/GoGrid style flat text format, Q-Layer/Sun style JSON as well as upconverting to [X]HTML complete with microformats et al - the Atom base is borrowed from Google's GData. There's not actually much to the core protocol (except things like ETags for proxying/caching and conditional retrieval) and everything from state control to search is handled by extensions. All "resources" (having dropped the concept of "workloads" and "containers", so compute, storage and networking objects), are identified by a UUID which you can GET from <entrypoint>/<uuid> (e.g. http://example.com/5c60a787-c523-4859-831f-de5356eb3975). They can link to each other using standard Atom "link" relations and these have attributes for information like interface/device, IP number, etc. That is, key information that would normally hide inside OVF (including information about collections of systems) is specified in OCCI - if the level of interoperatility gets to a sufficiently high level then we can migrate over time but we may be pleasantly surprised as we get into the format discussion and start pulling it all apart. Sam
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@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Tim Bray |Sent: Saturday, April 25, 2009 11:16 PM |To: Edmonds, AndrewX |Cc: occi-wg@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@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg
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@cisco.com] Sent: 26 April 2009 17:42 To: Tim Bray; Edmonds, AndrewX Cc: occi-wg@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@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Tim Bray |Sent: Saturday, April 25, 2009 11:16 PM |To: Edmonds, AndrewX |Cc: occi-wg@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@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.
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@intel.com] |Sent: Monday, April 27, 2009 1:48 PM |To: Krishna Sankar (ksankar); Tim Bray |Cc: occi-wg@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@cisco.com] |Sent: 26 April 2009 17:42 |To: Tim Bray; Edmonds, AndrewX |Cc: occi-wg@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@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On |Behalf ||Of Tim Bray ||Sent: Saturday, April 25, 2009 11:16 PM ||To: Edmonds, AndrewX ||Cc: occi-wg@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@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.
participants (7)
-
Alexis Richardson -
Edmonds, AndrewX -
Krishna Sankar (ksankar) -
Randy Bias -
Sam Johnston -
Tim Bray -
Wes Felter