Opinion Poll: IaaS or PaaS ?
Sam Johnston's timely IaaS feature matrix brings up some interesting issues, one in particular, what are the specific features that can be included in an IaaS. Many of the IaaS provider are also providing one or more operating systems while other are providing closer to bare metal. Is the OS part of the Infrastructure or part of the Platform ? The question is: " Do operating systems belong in IaaS or PaaS. " Please lets us know you opinion -cheers gary mazz
On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
The question is: " Do operating systems belong in IaaS or PaaS. "
Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, etc. you're venturing well into the underlying hardware fabric which is ultimately someone else's problem - I don't see any of these things appearing in current IaaS APIs[1]. Basically think of infrastructure services as everything up to the operating system interface (be that an API, CLI or a GUI). Platform services (PaaS) on the other hand include [most of] the solution stack... any app servers, databases, script/bytecode interpreters, etc. - think LAMP. You can just take your app and use it (in many was like it were a virtual machine - which is why the next step for us will be a small one). Software services (SaaS) then add the application itself. OCCI is most definitely IaaS. Sam 1. That is not to say they're not important - they are, particularly for "I can't believe it's not cloud" moreso than public cloud, but if they appear in OCCI they'll be optional.
I was on the same wavelength as you are until about a 3 days ago, I was getting xVM working on opensolaris. xVM para-virtualization has a concept of a virtual MAC address not tied to a physical MAC. This allows them to create virtual HBA devices that can request IP addresses from DHCP. The virtual MAC helps routers and switches find the VM when its instantiated or transported to another rack or facility. I'm reconsidered my past position on what's relegated to fabric in lieu of a more comprehensive definition of IaaS. Lets look at some provider models: 1) A provider has hard iron that they physically provision for a customer ( the dedicated hw model/ no sharing of anything) 2) A provider has pooled iron that they logically provision (fixed resources/dedicated hw) specific for a customer ( the LPAR model). This includes blades, minis, 100 cpu racks. 3) A provider has pooled iron that shared resource provisioning occurs across customers ( the dynamic model). Irrespective of how the provider model fulfills its services, each are providing specific items: CPUs, memory, network adapters, storage HBAs, raw disk, filers, networks, VPNs, load balancers, web caches, name servers, edge firewalls, etc... In the first case --- physical partitioning providers, the infrastructure is hard iron and no doubt fabric. In the second two models, LPAR and VM, all of the servers may be partially or completely visualized. We need to address what this really means for the both the providers and the consumers. Providers have a pool of resources they provision for each customer. I assume each set of resources would/can be organized into one or more federated accounts. Federations can be further subdivided into administrative resources groups (zones). Each federation is logically isolated from all other accounts for security and privacy constraints and possibly quality agreements. The quality, availability, responsiveness, besides types of services offered are several ways providers differentiate themselves. Consumers receiving federated pool of resources, can administer them according to their IT and business requirements. The administration can include fire walling internal to the federation, VPN connections between federations and zones, and balancing external workload across multiple applications servers, Essentially, executing the same organizational and administrative tasks occurring in private data centers. Unless there are hard requirements for physical isolation or dedicated hardware, consumers will not care whether their infrastructure is physically partitioned, implemented as LPARs, floating VMs or how closely services are linked to fabric resources.. Consumers will expect or require certain levels of quality from their service.. Bottom line: Consumer services are defined by the providers; not all providers offer the same services; and how a provider implements of their services, as far as occi concerns, are unrelated to their service offerings. IMO, I don't think we can exclude cloud service providers because their services are too "close" to the fabric. We need to include virtualized hardware parameters like MACs as well as other infrastructure services including DNS, firewalls and VPNs. In the world, there are going to be varying degrees of compatibility betweens cloud provider technologies and service offerings. Some differences can be easily be worked around, while other may be irreconcilable; while all supporting and implementing occi. For example, virtual MACs are a hard reality and a critical attribute for some providers. Even though they are not required by all providers, it may not be a good idea to exclude them. In this case, the OCCI can accommodate both type of providers by acting as a superset for network adapter configurations. A provider not requiring a MAC address for their operations can ignored the parameter. The idea that ALL occi cloud providers will be 100% inter-operating in the face of differentiated (missing or incompatible) service offering is unrealistic. For example, if a consumer has an application requiring infrastructure provided load balancing services, they cannot engage a provider not offering those services. The OCCI cannot reconcile providers with incompatible infrastructures. In this example, the OCCI can only provide a vehicle for the consumer to assess the capabilities of a provider. Reiterating, I think we need to include more virtualized services and vituralized hardware configurations. lemme get a few more cups of coffee... -gary Sam Johnston wrote:
On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
The question is: " Do operating systems belong in IaaS or PaaS. "
Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, etc. you're venturing well into the underlying hardware fabric which is ultimately someone else's problem - I don't see any of these things appearing in current IaaS APIs[1].
Basically think of infrastructure services as everything up to the operating system interface (be that an API, CLI or a GUI).
Platform services (PaaS) on the other hand include [most of] the solution stack... any app servers, databases, script/bytecode interpreters, etc. - think LAMP. You can just take your app and use it (in many was like it were a virtual machine - which is why the next step for us will be a small one).
Software services (SaaS) then add the application itself.
OCCI is most definitely IaaS.
Sam
1. That is not to say they're not important - they are, particularly for "I can't believe it's not cloud" moreso than public cloud, but if they appear in OCCI they'll be optional.
Dear Gary, dear All, sorry for interfering with your discussion, but I am only reading your Email list since a week. From my perspective, IaaS (and OCCI) only deals with an execution platform for (a collection of) virtual images. The operating system itself and the "virtual" hardware (Virtual MAC, ...) is part of the virtual image and therefore does not belong to an IaaS environment. Nevertheless, services like VPNs, DNS, and DHCP are services, which are typically provided by the infrastructure outside of the virtual machines and I would be happy if you would include a description of these services inside OCCI. Best Regards, André -- --------------------------------------------------------------- Jun.-Prof. Dr.-Ing. Andre Brinkmann Managing Director Paderborn Center for Parallel Computing University of Paderborn Fürstenallee 11 33102 Paderborn Germany --------------------------------------------------------------- Email: Andre.Brinkmann@uni-paderborn.de Phone: +49-5251-60 62 90 Fax: +49-5251-60 62 97 --------------------------------------------------------------- Am 14.06.2009 um 18:52 schrieb Gary Mazz:
I was on the same wavelength as you are until about a 3 days ago, I was getting xVM working on opensolaris. xVM para-virtualization has a concept of a virtual MAC address not tied to a physical MAC. This allows them to create virtual HBA devices that can request IP addresses from DHCP. The virtual MAC helps routers and switches find the VM when its instantiated or transported to another rack or facility.
I'm reconsidered my past position on what's relegated to fabric in lieu of a more comprehensive definition of IaaS.
Lets look at some provider models: 1) A provider has hard iron that they physically provision for a customer ( the dedicated hw model/ no sharing of anything) 2) A provider has pooled iron that they logically provision (fixed resources/dedicated hw) specific for a customer ( the LPAR model). This includes blades, minis, 100 cpu racks. 3) A provider has pooled iron that shared resource provisioning occurs across customers ( the dynamic model).
Irrespective of how the provider model fulfills its services, each are providing specific items: CPUs, memory, network adapters, storage HBAs, raw disk, filers, networks, VPNs, load balancers, web caches, name servers, edge firewalls, etc...
In the first case --- physical partitioning providers, the infrastructure is hard iron and no doubt fabric. In the second two models, LPAR and VM, all of the servers may be partially or completely visualized. We need to address what this really means for the both the providers and the consumers.
Providers have a pool of resources they provision for each customer. I assume each set of resources would/can be organized into one or more federated accounts. Federations can be further subdivided into administrative resources groups (zones). Each federation is logically isolated from all other accounts for security and privacy constraints and possibly quality agreements. The quality, availability, responsiveness, besides types of services offered are several ways providers differentiate themselves.
Consumers receiving federated pool of resources, can administer them according to their IT and business requirements. The administration can include fire walling internal to the federation, VPN connections between federations and zones, and balancing external workload across multiple applications servers, Essentially, executing the same organizational and administrative tasks occurring in private data centers.
Unless there are hard requirements for physical isolation or dedicated hardware, consumers will not care whether their infrastructure is physically partitioned, implemented as LPARs, floating VMs or how closely services are linked to fabric resources.. Consumers will expect or require certain levels of quality from their service..
Bottom line: Consumer services are defined by the providers; not all providers offer the same services; and how a provider implements of their services, as far as occi concerns, are unrelated to their service offerings.
IMO, I don't think we can exclude cloud service providers because their services are too "close" to the fabric. We need to include virtualized hardware parameters like MACs as well as other infrastructure services including DNS, firewalls and VPNs.
In the world, there are going to be varying degrees of compatibility betweens cloud provider technologies and service offerings. Some differences can be easily be worked around, while other may be irreconcilable; while all supporting and implementing occi.
For example, virtual MACs are a hard reality and a critical attribute for some providers. Even though they are not required by all providers, it may not be a good idea to exclude them. In this case, the OCCI can accommodate both type of providers by acting as a superset for network adapter configurations. A provider not requiring a MAC address for their operations can ignored the parameter.
The idea that ALL occi cloud providers will be 100% inter-operating in the face of differentiated (missing or incompatible) service offering is unrealistic. For example, if a consumer has an application requiring infrastructure provided load balancing services, they cannot engage a provider not offering those services. The OCCI cannot reconcile providers with incompatible infrastructures. In this example, the OCCI can only provide a vehicle for the consumer to assess the capabilities of a provider.
Reiterating, I think we need to include more virtualized services and vituralized hardware configurations.
lemme get a few more cups of coffee...
-gary
Sam Johnston wrote:
On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
The question is: " Do operating systems belong in IaaS or PaaS. "
Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, etc. you're venturing well into the underlying hardware fabric which is ultimately someone else's problem - I don't see any of these things appearing in current IaaS APIs[1].
Basically think of infrastructure services as everything up to the operating system interface (be that an API, CLI or a GUI).
Platform services (PaaS) on the other hand include [most of] the solution stack... any app servers, databases, script/bytecode interpreters, etc. - think LAMP. You can just take your app and use it (in many was like it were a virtual machine - which is why the next step for us will be a small one).
Software services (SaaS) then add the application itself.
OCCI is most definitely IaaS.
Sam
1. That is not to say they're not important - they are, particularly for "I can't believe it's not cloud" moreso than public cloud, but if they appear in OCCI they'll be optional.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Jun 14, 2009, at 11:10 AM, André Brinkmann wrote:
sorry for interfering with your discussion, but I am only reading your Email list since a week. From my perspective, IaaS (and OCCI) only deals with an execution platform for (a collection of) virtual images. The operating system itself and the "virtual" hardware (Virtual MAC, ...) is part of the virtual image and therefore does not belong to an IaaS environment.
Actually, I think this is provably untrue. The virtual hardware will almost certainly belong to the infrastructure and not the VM itself. For example, right now GoGrid provides 3 NICs, but Amazon provides 1. Both are Xen-based platforms. Other systems provide arbitrary numbers of NICs. Since the virtual hardware is supplied by the underlying hypervisor layer and it's configuration the virtual hardware is part of the IaaS platform. In addition, most of the hypervisors request you to use Ethernet MACs that have Vendor IDs relevant to the hypervisor under which they are used. For example, VMware uses 00:0c:29 for dynamically assigned MACs. This leaves only 16M possible Ethernet MACs across all VMware installations. The risk of collision when moving a VMware VM from one cloud to another is very high. Because of this vendors will almost certainly provide (and hardcode for security reasons) the MAC addresses for servers. In other words, the virtual hardware and the virtual MAC are tied to the IaaS platform and not the VM. One can certainly argue whether the OS is the bottom layer of PaaS or the top layer of IaaS, but there is absolutely no doubt that it's the primary interface between the two. I would argue that the traditional notion of OS as a platform comes from the idea that the OS provides a set of runtimes (libraries, resources, and facilities) upon which you can 'load-your-code-and-go'. So, if platforms are 'load-your-code-and-go' systems, then an OS itself is not a platform. By default not every OS is ready to have code loaded and ready to go after a fresh install. Most require some significant configuration. So if we want to split hairs, an 'OS' is probably the top layer of an IaaS platform and a 'configured OS' is probably the bottom layer of a PaaS. BUT, if we dig deeper and look at runtimes that don't sit on a specific OS (JVM, Mono, CLR, etc.) then one has to assume that while the run times are typically attached to an OS, they don't have to be.
Nevertheless, services like VPNs, DNS, and DHCP are services, which are typically provided by the infrastructure outside of the virtual machines and I would be happy if you would include a description of these services inside OCCI.
I wrote this up fairly extensively here: Defining Infrastructure Clouds | Cloudscaling Thanks, --Randy Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
Hello Randy, thank you for the explanations. Nevertheless, there are still some open issues (at least from my side); Am 30.06.2009 um 19:59 schrieb Randy Bias:
On Jun 14, 2009, at 11:10 AM, André Brinkmann wrote:
sorry for interfering with your discussion, but I am only reading your Email list since a week. From my perspective, IaaS (and OCCI) only deals with an execution platform for (a collection of) virtual images. The operating system itself and the "virtual" hardware (Virtual MAC, ...) is part of the virtual image and therefore does not belong to an IaaS environment.
Actually, I think this is provably untrue. The virtual hardware will almost certainly belong to the infrastructure and not the VM itself. For example, right now GoGrid provides 3 NICs, but Amazon provides 1. Both are Xen-based platforms. Other systems provide arbitrary numbers of NICs. Since the virtual hardware is supplied by the underlying hypervisor layer and it's configuration the virtual hardware is part of the IaaS platform.
Your point is (in this case unfortunately) correct. I think that this is a drawback of current IaaS providers. In principle, the restriction to a limited number of NICs leads to vendor lock-in, e.g. it might become difficult to port applications from GoGrid back to Amazon.
In addition, most of the hypervisors request you to use Ethernet MACs that have Vendor IDs relevant to the hypervisor under which they are used. For example, VMware uses 00:0c:29 for dynamically assigned MACs. This leaves only 16M possible Ethernet MACs across all VMware installations. The risk of collision when moving a VMware VM from one cloud to another is very high. Because of this vendors will almost certainly provide (and hardcode for security reasons) the MAC addresses for servers.
In other words, the virtual hardware and the virtual MAC are tied to the IaaS platform and not the VM.
Correct and it also makes sense, as the MAC address in a conventional system is also part of a physical machine and therefor part of the infrastructure.
One can certainly argue whether the OS is the bottom layer of PaaS or the top layer of IaaS, but there is absolutely no doubt that it's the primary interface between the two.
I would argue that the traditional notion of OS as a platform comes from the idea that the OS provides a set of runtimes (libraries, resources, and facilities) upon which you can 'load-your-code-and-go'.
So, if platforms are 'load-your-code-and-go' systems, then an OS itself is not a platform. By default not every OS is ready to have code loaded and ready to go after a fresh install. Most require some significant configuration.
So if we want to split hairs, an 'OS' is probably the top layer of an IaaS platform and a 'configured OS' is probably the bottom layer of a PaaS.
I do not want to split hairs, but I am interested (from a customer perspective) to be able to deploy arbitrary OS-images inside my virtual machine, so the OS is not part of the service offered by the Iaas-provider.
BUT, if we dig deeper and look at runtimes that don't sit on a specific OS (JVM, Mono, CLR, etc.) then one has to assume that while the run times are typically attached to an OS, they don't have to be.
Nevertheless, services like VPNs, DNS, and DHCP are services, which are typically provided by the infrastructure outside of the virtual machines and I would be happy if you would include a description of these services inside OCCI.
I wrote this up fairly extensively here:
Defining Infrastructure Clouds | Cloudscaling
Thank you for your comments André
Thanks,
--Randy
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
Regarding: "I do not want to split hairs, but I am interested (from a customer perspective) to be able to deploy arbitrary OS-images inside my virtual machine, so the OS is not part of the service offered by the Iaas-provider." The OS selection may have dependencies on the IaaS owing to hardware architectures it supports (i386, x86_64, PPC, MIPS etc) so it may not be possible to run arbitrary OS that assume a particular h.architecture. Currently the only sure way to guarantee arbitrary OS deployment could be the provisioning of instruction set emulation within a hypervisor. Other than that as a simpler solution, the IaaS provider would have to state what hardware architectures it could support (though would limit arbitrary OS deployment). .2c Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Andre Brinkmann Sent: 03 July 2009 15:35 To: Randy Bias Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? Hello Randy, thank you for the explanations. Nevertheless, there are still some open issues (at least from my side); Am 30.06.2009 um 19:59 schrieb Randy Bias:
On Jun 14, 2009, at 11:10 AM, André Brinkmann wrote:
sorry for interfering with your discussion, but I am only reading your Email list since a week. From my perspective, IaaS (and OCCI) only deals with an execution platform for (a collection of) virtual images. The operating system itself and the "virtual" hardware (Virtual MAC, ...) is part of the virtual image and therefore does not belong to an IaaS environment.
Actually, I think this is provably untrue. The virtual hardware will almost certainly belong to the infrastructure and not the VM itself. For example, right now GoGrid provides 3 NICs, but Amazon provides 1. Both are Xen-based platforms. Other systems provide arbitrary numbers of NICs. Since the virtual hardware is supplied by the underlying hypervisor layer and it's configuration the virtual hardware is part of the IaaS platform.
Your point is (in this case unfortunately) correct. I think that this is a drawback of current IaaS providers. In principle, the restriction to a limited number of NICs leads to vendor lock-in, e.g. it might become difficult to port applications from GoGrid back to Amazon.
In addition, most of the hypervisors request you to use Ethernet MACs that have Vendor IDs relevant to the hypervisor under which they are used. For example, VMware uses 00:0c:29 for dynamically assigned MACs. This leaves only 16M possible Ethernet MACs across all VMware installations. The risk of collision when moving a VMware VM from one cloud to another is very high. Because of this vendors will almost certainly provide (and hardcode for security reasons) the MAC addresses for servers.
In other words, the virtual hardware and the virtual MAC are tied to the IaaS platform and not the VM.
Correct and it also makes sense, as the MAC address in a conventional system is also part of a physical machine and therefor part of the infrastructure.
One can certainly argue whether the OS is the bottom layer of PaaS or the top layer of IaaS, but there is absolutely no doubt that it's the primary interface between the two.
I would argue that the traditional notion of OS as a platform comes from the idea that the OS provides a set of runtimes (libraries, resources, and facilities) upon which you can 'load-your-code-and-go'.
So, if platforms are 'load-your-code-and-go' systems, then an OS itself is not a platform. By default not every OS is ready to have code loaded and ready to go after a fresh install. Most require some significant configuration.
So if we want to split hairs, an 'OS' is probably the top layer of an IaaS platform and a 'configured OS' is probably the bottom layer of a PaaS.
I do not want to split hairs, but I am interested (from a customer perspective) to be able to deploy arbitrary OS-images inside my virtual machine, so the OS is not part of the service offered by the Iaas-provider.
BUT, if we dig deeper and look at runtimes that don't sit on a specific OS (JVM, Mono, CLR, etc.) then one has to assume that while the run times are typically attached to an OS, they don't have to be.
Nevertheless, services like VPNs, DNS, and DHCP are services, which are typically provided by the infrastructure outside of the virtual machines and I would be happy if you would include a description of these services inside OCCI.
I wrote this up fairly extensively here:
Defining Infrastructure Clouds | Cloudscaling
Thank you for your comments André
Thanks,
--Randy
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
_______________________________________________ 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.
Hello Andy, Am 03.07.2009 um 16:52 schrieb Edmonds, AndrewX:
Regarding: "I do not want to split hairs, but I am interested (from a customer perspective) to be able to deploy arbitrary OS-images inside my virtual machine, so the OS is not part of the service offered by the Iaas-provider."
The OS selection may have dependencies on the IaaS owing to hardware architectures it supports (i386, x86_64, PPC, MIPS etc) so it may not be possible to run arbitrary OS that assume a particular h.architecture. Currently the only sure way to guarantee arbitrary OS deployment could be the provisioning of instruction set emulation within a hypervisor. Other than that as a simpler solution, the IaaS provider would have to state what hardware architectures it could support (though would limit arbitrary OS deployment).
again true. What I wanted to say is that I want to be able to deploy arbitrary OS-images inside my virtual machine as long as there are no physical constraint hindering this deployment and that I do not want to have to take an OS-image from my IaaS-Provider, which might limit my configuration freedom and my choice to switch between different IaaS-providers. Best Regards, André
.2c
Andy
-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Andre Brinkmann Sent: 03 July 2009 15:35 To: Randy Bias Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
Hello Randy,
thank you for the explanations. Nevertheless, there are still some open issues (at least from my side);
Am 30.06.2009 um 19:59 schrieb Randy Bias:
On Jun 14, 2009, at 11:10 AM, André Brinkmann wrote:
sorry for interfering with your discussion, but I am only reading your Email list since a week. From my perspective, IaaS (and OCCI) only deals with an execution platform for (a collection of) virtual images. The operating system itself and the "virtual" hardware (Virtual MAC, ...) is part of the virtual image and therefore does not belong to an IaaS environment.
Actually, I think this is provably untrue. The virtual hardware will almost certainly belong to the infrastructure and not the VM itself. For example, right now GoGrid provides 3 NICs, but Amazon provides 1. Both are Xen-based platforms. Other systems provide arbitrary numbers of NICs. Since the virtual hardware is supplied by the underlying hypervisor layer and it's configuration the virtual hardware is part of the IaaS platform.
Your point is (in this case unfortunately) correct. I think that this is a drawback of current IaaS providers. In principle, the restriction to a limited number of NICs leads to vendor lock-in, e.g. it might become difficult to port applications from GoGrid back to Amazon.
In addition, most of the hypervisors request you to use Ethernet MACs that have Vendor IDs relevant to the hypervisor under which they are used. For example, VMware uses 00:0c:29 for dynamically assigned MACs. This leaves only 16M possible Ethernet MACs across all VMware installations. The risk of collision when moving a VMware VM from one cloud to another is very high. Because of this vendors will almost certainly provide (and hardcode for security reasons) the MAC addresses for servers.
In other words, the virtual hardware and the virtual MAC are tied to the IaaS platform and not the VM.
Correct and it also makes sense, as the MAC address in a conventional system is also part of a physical machine and therefor part of the infrastructure.
One can certainly argue whether the OS is the bottom layer of PaaS or the top layer of IaaS, but there is absolutely no doubt that it's the primary interface between the two.
I would argue that the traditional notion of OS as a platform comes from the idea that the OS provides a set of runtimes (libraries, resources, and facilities) upon which you can 'load-your-code-and- go'.
So, if platforms are 'load-your-code-and-go' systems, then an OS itself is not a platform. By default not every OS is ready to have code loaded and ready to go after a fresh install. Most require some significant configuration.
So if we want to split hairs, an 'OS' is probably the top layer of an IaaS platform and a 'configured OS' is probably the bottom layer of a PaaS.
I do not want to split hairs, but I am interested (from a customer perspective) to be able to deploy arbitrary OS-images inside my virtual machine, so the OS is not part of the service offered by the Iaas-provider.
BUT, if we dig deeper and look at runtimes that don't sit on a specific OS (JVM, Mono, CLR, etc.) then one has to assume that while the run times are typically attached to an OS, they don't have to be.
Nevertheless, services like VPNs, DNS, and DHCP are services, which are typically provided by the infrastructure outside of the virtual machines and I would be happy if you would include a description of these services inside OCCI.
I wrote this up fairly extensively here:
Defining Infrastructure Clouds | Cloudscaling
Thank you for your comments
André
Thanks,
--Randy
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
_______________________________________________ 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.
Two points (actually four ;o)): a) If OS is not part of an IaaS, then IaaS effectively is HaaS (Hypervisor as a Service); a virtual version of the hardware - nothing more, nothing less b) Which is not quite true ( as Randy mentions); in effect IaaS = HaaS + Cloud Infrastructure Services(compute, network, storage) VPNs, DNS, DHCP, MAC Address all come under this moniker of Cloud Infrastructure Services b) I think the question is not running any OS on any HaaS (which would be nice, but most probably is not totally practical) but the ability to customize the *supported* OS layer, rather than use whatever configuration the IaaS provider has setup. For example, if an IaaS/HaaS supports Ubuntu, a cloud service consumer still would like to run its version of Ubuntu, customized for the application it wants to run. Remember, Andre talks about arbitrary OS-images not arbitrary OSs ! c) And this makes more sense when we want to move the cloud application stack around or run a pickled cloud application stack. Cheers <k/> |-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Edmonds, AndrewX |Sent: Friday, July 03, 2009 7:53 AM |To: Andre Brinkmann; Randy Bias |Cc: occi-wg@ogf.org |Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? | |Regarding: |"I do not want to split hairs, but I am interested (from a customer |perspective) to be able to deploy arbitrary OS-images inside my virtual |machine, so the OS is not part of the service offered by the Iaas- |provider." | |The OS selection may have dependencies on the IaaS owing to hardware |architectures it supports (i386, x86_64, PPC, MIPS etc) so it may not be |possible to run arbitrary OS that assume a particular h.architecture. |Currently the only sure way to guarantee arbitrary OS deployment could |be the provisioning of instruction set emulation within a hypervisor. |Other than that as a simpler solution, the IaaS provider would have to |state what hardware architectures it could support (though would limit |arbitrary OS deployment). | |.2c | |Andy | |-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Andre Brinkmann |Sent: 03 July 2009 15:35 |To: Randy Bias |Cc: occi-wg@ogf.org |Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? | |Hello Randy, | |thank you for the explanations. Nevertheless, there are still some |open issues (at least from my side); | |Am 30.06.2009 um 19:59 schrieb Randy Bias: | |> |> On Jun 14, 2009, at 11:10 AM, André Brinkmann wrote: |>> sorry for interfering with your discussion, but I am only reading |>> your Email list since a week. From my perspective, IaaS (and OCCI) |>> only deals with an execution platform for (a collection of) virtual |>> images. The operating system itself and the "virtual" hardware |>> (Virtual MAC, ...) is part of the virtual image and therefore does |>> not belong to an IaaS environment. |> |> Actually, I think this is provably untrue. The virtual hardware |> will almost certainly belong to the infrastructure and not the VM |> itself. For example, right now GoGrid provides 3 NICs, but Amazon |> provides 1. Both are Xen-based platforms. Other systems provide |> arbitrary numbers of NICs. Since the virtual hardware is supplied |> by the underlying hypervisor layer and it's configuration the |> virtual hardware is part of the IaaS platform. |> | |Your point is (in this case unfortunately) correct. I think that this |is a drawback of current IaaS providers. In principle, the restriction |to a limited number of NICs leads to vendor lock-in, e.g. it might |become difficult to port applications from GoGrid back to Amazon. | |> In addition, most of the hypervisors request you to use Ethernet |> MACs that have Vendor IDs relevant to the hypervisor under which |> they are used. For example, VMware uses 00:0c:29 for dynamically |> assigned MACs. This leaves only 16M possible Ethernet MACs across |> all VMware installations. The risk of collision when moving a |> VMware VM from one cloud to another is very high. Because of this |> vendors will almost certainly provide (and hardcode for security |> reasons) the MAC addresses for servers. |> |> In other words, the virtual hardware and the virtual MAC are tied to |> the IaaS platform and not the VM. |> | |Correct and it also makes sense, as the MAC address in a conventional |system is also part of a physical machine and therefor part of the |infrastructure. | |> One can certainly argue whether the OS is the bottom layer of PaaS |> or the top layer of IaaS, but there is absolutely no doubt that it's |> the primary interface between the two. |> |> I would argue that the traditional notion of OS as a platform comes |> from the idea that the OS provides a set of runtimes (libraries, |> resources, and facilities) upon which you can 'load-your-code-and-go'. |> |> So, if platforms are 'load-your-code-and-go' systems, then an OS |> itself is not a platform. By default not every OS is ready to have |> code loaded and ready to go after a fresh install. Most require |> some significant configuration. |> |> So if we want to split hairs, an 'OS' is probably the top layer of |> an IaaS platform and a 'configured OS' is probably the bottom layer |> of a PaaS. |> | |I do not want to split hairs, but I am interested (from a customer |perspective) to be able to deploy arbitrary OS-images inside my |virtual machine, so the OS is not part of the service offered by the |Iaas-provider. | |> BUT, if we dig deeper and look at runtimes that don't sit on a |> specific OS (JVM, Mono, CLR, etc.) then one has to assume that while |> the run times are typically attached to an OS, they don't have to be. |> |>> Nevertheless, services like VPNs, DNS, and DHCP are services, which |>> are typically provided by the infrastructure outside of the virtual |>> machines and I would be happy if you would include a description of |>> these services inside OCCI. |> |> |> I wrote this up fairly extensively here: |> |> Defining Infrastructure Clouds | Cloudscaling |> | |Thank you for your comments | |André | |> |> Thanks, |> |> |> --Randy |> |> |> Randy Bias, Cloud Strategist |> +1 (415) 939-8507 [m], randyb@neotactics.com |> BLOG: http://cloudscaling.com |> | |_______________________________________________ |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. |_______________________________________________ |occi-wg mailing list |occi-wg@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg
On Jul 3, 2009, at 12:22 PM, Krishna Sankar (ksankar) wrote:
a) If OS is not part of an IaaS, then IaaS effectively is HaaS (Hypervisor as a Service); a virtual version of the hardware - nothing more, nothing less b) Which is not quite true ( as Randy mentions); in effect IaaS = HaaS + Cloud Infrastructure Services(compute, network, storage) VPNs, DNS, DHCP, MAC Address all come under this moniker of Cloud Infrastructure Services
Yes.
b) I think the question is not running any OS on any HaaS (which would be nice, but most probably is not totally practical) but the ability to customize the *supported* OS layer, rather than use whatever configuration the IaaS provider has setup. For example, if an IaaS/HaaS supports Ubuntu, a cloud service consumer still would like to run its version of Ubuntu, customized for the application it wants to run. Remember, Andre talks about arbitrary OS-images not arbitrary OSs !
I don't think it's unreasonable to allow uploading images. As I said, Amazon has limited supported for this. Unfortunately, most clouds are not spending the time to make this work. I think there is actually an opportunity here for someone to create an on-demand conversion service. I would certainly pay for it.
c) And this makes more sense when we want to move the cloud application stack around or run a pickled cloud application stack.
Yep. --Randy Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
On Jul 3, 2009, at 7:52 AM, Edmonds, AndrewX wrote:
Regarding: "I do not want to split hairs, but I am interested (from a customer perspective) to be able to deploy arbitrary OS-images inside my virtual machine, so the OS is not part of the service offered by the Iaas-provider."
The OS selection may have dependencies on the IaaS owing to hardware architectures it supports (i386, x86_64, PPC, MIPS etc) so it may not be possible to run arbitrary OS that assume a particular h.architecture. Currently the only sure way to guarantee arbitrary OS deployment could be the provisioning of instruction set emulation within a hypervisor. Other than that as a simpler solution, the IaaS provider would have to state what hardware architectures it could support (though would limit arbitrary OS deployment).
I'm not sure this is true. Clearly x86 has 'won' at this point. You can certainly come up with edge cases, but for the vast majority of the market place no-x86 platforms don't matter. The bigger problem is that hypervisor variance between providers means that it's not as easy to simply upload any Xen or VMware image. You actually need to match hypervisors closely AND make sure the appropriate paravirt disk/net drivers are installed into the image before upload (if possible). Alternatively, the provider could dynamically convert images on the fly, but this is a non-trivial capability that is multiplicative in terms of the number of configurations that would need to be supported to be useful to everyone. Still, you could get a lot of traction just doing VMware -> Xen in PVM or HVM mode. --Randy Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
I couldn't agree more. This was a capability I lobbied for at GoGrid. Amazon provides this to a limited degree and it would be ideal if all IaaS providers allowed you to upload images. Unfortunately, we're not quite there yet in terms of market maturity. This does lead back to the question of "How do I get # NICs in a configuration of <foo>?" In an ideal world this would be possible, but unfortunately, right now the way that IaaS systems are being designed is unquestionably limited in scope. For one thing, most of them tie things like the # of NICs and the network configuration directly to the underlying physical infrastructure's topology, which is clearly wrong. They do this because the technology is not quite there to allow a true abstraction layer between the physical network topology and the logical cloud network topology on top of it. We need very flexible network virtualization capabilities like those possible with OpenFlow. I'm afraid this is a ways out as most of the incumbent network hardware manufacturers (Cisco, Juniper, et al) are too blind to see a future where network hardware is as big a commodity as the x86 platform. Not to mention it's a huge threat to their business models. But I'm jumping way ahead of myself. I'll outline this in detail in some blog postings in the near future. Thanks, --Randy On Jul 3, 2009, at 7:35 AM, André Brinkmann wrote:
I do not want to split hairs, but I am interested (from a customer perspective) to be able to deploy arbitrary OS-images inside my virtual machine, so the OS is not part of the service offered by the Iaas-provider.
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
Dear Gary, dear All, sorry for interfering with your discussion, but I am only reading your Email list since a week. From my perspective, IaaS (and OCCI) only deals with an execution platform for (a collection of) virtual images. The operating system itself and the "virtual" hardware (Virtual MAC, ...) is part of the virtual image and therefore does not belong to an IaaS environment. Nevertheless, services like VPNs, DNS, and DHCP are services, which are typically provided by the infrastructure outside of the virtual machines and I would be happy if you would include a description of these services inside OCCI. Best Regards, André -- --------------------------------------------------------------- Jun.-Prof. Dr.-Ing. Andre Brinkmann Managing Director Paderborn Center for Parallel Computing University of Paderborn Fürstenallee 11 33102 Paderborn Germany --------------------------------------------------------------- Email: Andre.Brinkmann@uni-paderborn.de Phone: +49-5251-60 62 90 Fax: +49-5251-60 62 97 --------------------------------------------------------------- Am 14.06.2009 um 18:52 schrieb Gary Mazz:
I was on the same wavelength as you are until about a 3 days ago, I was getting xVM working on opensolaris. xVM para-virtualization has a concept of a virtual MAC address not tied to a physical MAC. This allows them to create virtual HBA devices that can request IP addresses from DHCP. The virtual MAC helps routers and switches find the VM when its instantiated or transported to another rack or facility.
I'm reconsidered my past position on what's relegated to fabric in lieu of a more comprehensive definition of IaaS.
Lets look at some provider models: 1) A provider has hard iron that they physically provision for a customer ( the dedicated hw model/ no sharing of anything) 2) A provider has pooled iron that they logically provision (fixed resources/dedicated hw) specific for a customer ( the LPAR model). This includes blades, minis, 100 cpu racks. 3) A provider has pooled iron that shared resource provisioning occurs across customers ( the dynamic model).
Irrespective of how the provider model fulfills its services, each are providing specific items: CPUs, memory, network adapters, storage HBAs, raw disk, filers, networks, VPNs, load balancers, web caches, name servers, edge firewalls, etc...
In the first case --- physical partitioning providers, the infrastructure is hard iron and no doubt fabric. In the second two models, LPAR and VM, all of the servers may be partially or completely visualized. We need to address what this really means for the both the providers and the consumers.
Providers have a pool of resources they provision for each customer. I assume each set of resources would/can be organized into one or more federated accounts. Federations can be further subdivided into administrative resources groups (zones). Each federation is logically isolated from all other accounts for security and privacy constraints and possibly quality agreements. The quality, availability, responsiveness, besides types of services offered are several ways providers differentiate themselves.
Consumers receiving federated pool of resources, can administer them according to their IT and business requirements. The administration can include fire walling internal to the federation, VPN connections between federations and zones, and balancing external workload across multiple applications servers, Essentially, executing the same organizational and administrative tasks occurring in private data centers.
Unless there are hard requirements for physical isolation or dedicated hardware, consumers will not care whether their infrastructure is physically partitioned, implemented as LPARs, floating VMs or how closely services are linked to fabric resources.. Consumers will expect or require certain levels of quality from their service..
Bottom line: Consumer services are defined by the providers; not all providers offer the same services; and how a provider implements of their services, as far as occi concerns, are unrelated to their service offerings.
IMO, I don't think we can exclude cloud service providers because their services are too "close" to the fabric. We need to include virtualized hardware parameters like MACs as well as other infrastructure services including DNS, firewalls and VPNs.
In the world, there are going to be varying degrees of compatibility betweens cloud provider technologies and service offerings. Some differences can be easily be worked around, while other may be irreconcilable; while all supporting and implementing occi.
For example, virtual MACs are a hard reality and a critical attribute for some providers. Even though they are not required by all providers, it may not be a good idea to exclude them. In this case, the OCCI can accommodate both type of providers by acting as a superset for network adapter configurations. A provider not requiring a MAC address for their operations can ignored the parameter.
The idea that ALL occi cloud providers will be 100% inter-operating in the face of differentiated (missing or incompatible) service offering is unrealistic. For example, if a consumer has an application requiring infrastructure provided load balancing services, they cannot engage a provider not offering those services. The OCCI cannot reconcile providers with incompatible infrastructures. In this example, the OCCI can only provide a vehicle for the consumer to assess the capabilities of a provider.
Reiterating, I think we need to include more virtualized services and vituralized hardware configurations.
lemme get a few more cups of coffee...
-gary
Sam Johnston wrote:
On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
The question is: " Do operating systems belong in IaaS or PaaS. "
Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, etc. you're venturing well into the underlying hardware fabric which is ultimately someone else's problem - I don't see any of these things appearing in current IaaS APIs[1].
Basically think of infrastructure services as everything up to the operating system interface (be that an API, CLI or a GUI).
Platform services (PaaS) on the other hand include [most of] the solution stack... any app servers, databases, script/bytecode interpreters, etc. - think LAMP. You can just take your app and use it (in many was like it were a virtual machine - which is why the next step for us will be a small one).
Software services (SaaS) then add the application itself.
OCCI is most definitely IaaS.
Sam
1. That is not to say they're not important - they are, particularly for "I can't believe it's not cloud" moreso than public cloud, but if they appear in OCCI they'll be optional.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
My classic blog post on this is here: http://cloudscaling.com/blog/cloud-computing/defining-infrastructure-clouds I don't cover OS directly, but my $0.02 are this: - Platforms are run time environments ('load-your-code-and-go') - Traditionally folks have lumped OS and run time environments together - Run time environments don't have to be tightly coupled to OS (e.g. JVM and .NET/Mono) - Confusion comes from runtime environments an OSes being tightly coupled historically So, bottom line is the OS is probably (ultimately) the top of the IaaS stack and interfaces directly to the run time platform environments. It's the infrastructure (compute, storage, network) abstraction layer for the run time environment in effect. --Randy On Jun 14, 2009, at 11:15 AM, André Brinkmann wrote:
Dear Gary, dear All,
sorry for interfering with your discussion, but I am only reading your Email list since a week. From my perspective, IaaS (and OCCI) only deals with an execution platform for (a collection of) virtual images. The operating system itself and the "virtual" hardware (Virtual MAC, ...) is part of the virtual image and therefore does not belong to an IaaS environment.
Nevertheless, services like VPNs, DNS, and DHCP are services, which are typically provided by the infrastructure outside of the virtual machines and I would be happy if you would include a description of these services inside OCCI.
Best Regards,
André
-- --------------------------------------------------------------- Jun.-Prof. Dr.-Ing. Andre Brinkmann Managing Director
Paderborn Center for Parallel Computing University of Paderborn Fürstenallee 11 33102 Paderborn
Germany --------------------------------------------------------------- Email: Andre.Brinkmann@uni-paderborn.de Phone: +49-5251-60 62 90 Fax: +49-5251-60 62 97 ---------------------------------------------------------------
Am 14.06.2009 um 18:52 schrieb Gary Mazz:
I was on the same wavelength as you are until about a 3 days ago, I was getting xVM working on opensolaris. xVM para-virtualization has a concept of a virtual MAC address not tied to a physical MAC. This allows them to create virtual HBA devices that can request IP addresses from DHCP. The virtual MAC helps routers and switches find the VM when its instantiated or transported to another rack or facility.
I'm reconsidered my past position on what's relegated to fabric in lieu of a more comprehensive definition of IaaS.
Lets look at some provider models: 1) A provider has hard iron that they physically provision for a customer ( the dedicated hw model/ no sharing of anything) 2) A provider has pooled iron that they logically provision (fixed resources/dedicated hw) specific for a customer ( the LPAR model). This includes blades, minis, 100 cpu racks. 3) A provider has pooled iron that shared resource provisioning occurs across customers ( the dynamic model).
Irrespective of how the provider model fulfills its services, each are providing specific items: CPUs, memory, network adapters, storage HBAs, raw disk, filers, networks, VPNs, load balancers, web caches, name servers, edge firewalls, etc...
In the first case --- physical partitioning providers, the infrastructure is hard iron and no doubt fabric. In the second two models, LPAR and VM, all of the servers may be partially or completely visualized. We need to address what this really means for the both the providers and the consumers.
Providers have a pool of resources they provision for each customer. I assume each set of resources would/can be organized into one or more federated accounts. Federations can be further subdivided into administrative resources groups (zones). Each federation is logically isolated from all other accounts for security and privacy constraints and possibly quality agreements. The quality, availability, responsiveness, besides types of services offered are several ways providers differentiate themselves.
Consumers receiving federated pool of resources, can administer them according to their IT and business requirements. The administration can include fire walling internal to the federation, VPN connections between federations and zones, and balancing external workload across multiple applications servers, Essentially, executing the same organizational and administrative tasks occurring in private data centers.
Unless there are hard requirements for physical isolation or dedicated hardware, consumers will not care whether their infrastructure is physically partitioned, implemented as LPARs, floating VMs or how closely services are linked to fabric resources.. Consumers will expect or require certain levels of quality from their service..
Bottom line: Consumer services are defined by the providers; not all providers offer the same services; and how a provider implements of their services, as far as occi concerns, are unrelated to their service offerings.
IMO, I don't think we can exclude cloud service providers because their services are too "close" to the fabric. We need to include virtualized hardware parameters like MACs as well as other infrastructure services including DNS, firewalls and VPNs.
In the world, there are going to be varying degrees of compatibility betweens cloud provider technologies and service offerings. Some differences can be easily be worked around, while other may be irreconcilable; while all supporting and implementing occi.
For example, virtual MACs are a hard reality and a critical attribute for some providers. Even though they are not required by all providers, it may not be a good idea to exclude them. In this case, the OCCI can accommodate both type of providers by acting as a superset for network adapter configurations. A provider not requiring a MAC address for their operations can ignored the parameter.
The idea that ALL occi cloud providers will be 100% inter-operating in the face of differentiated (missing or incompatible) service offering is unrealistic. For example, if a consumer has an application requiring infrastructure provided load balancing services, they cannot engage a provider not offering those services. The OCCI cannot reconcile providers with incompatible infrastructures. In this example, the OCCI can only provide a vehicle for the consumer to assess the capabilities of a provider.
Reiterating, I think we need to include more virtualized services and vituralized hardware configurations.
lemme get a few more cups of coffee...
-gary
Sam Johnston wrote:
On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com <mailto:garymazzaferro@gmail.com>> wrote:
The question is: " Do operating systems belong in IaaS or PaaS. "
Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, etc. you're venturing well into the underlying hardware fabric which is ultimately someone else's problem - I don't see any of these things appearing in current IaaS APIs[1].
Basically think of infrastructure services as everything up to the operating system interface (be that an API, CLI or a GUI).
Platform services (PaaS) on the other hand include [most of] the solution stack... any app servers, databases, script/bytecode interpreters, etc. - think LAMP. You can just take your app and use it (in many was like it were a virtual machine - which is why the next step for us will be a small one).
Software services (SaaS) then add the application itself.
OCCI is most definitely IaaS.
Sam
1. That is not to say they're not important - they are, particularly for "I can't believe it's not cloud" moreso than public cloud, but if they appear in OCCI they'll be optional.
_______________________________________________ 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
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
Gary, Couple of points: |provider not offering those services. The OCCI cannot reconcile |providers with incompatible infrastructures. In this example, the OCCI |can only provide a vehicle for the consumer to assess the capabilities |of a provider. <KS> We only provide interfaces et al. But it is not binary - folks can offer a subset or superset of capabilities </KS> |Reiterating, I think we need to include more virtualized services and |virtualized hardware configurations. <KS> I thought that is what we are doing ... because, underneath the instances can handle the specification in a multitude of ways and we are not prescriptive of any instantiation ... </KS> |lemme get a few more cups of coffee... <KS> Good idea ... am going to get some tea and will be back in a few ... too many discussions internally and externally on this ... need more juice ...</KS> Cheers <k/> |-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Gary Mazz |Sent: Sunday, June 14, 2009 9:53 AM |To: Sam Johnston |Cc: occi-wg@ogf.org |Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? | | |I was on the same wavelength as you are until about a 3 days ago, I was |getting xVM working on opensolaris. xVM para-virtualization has a |concept of a virtual MAC address not tied to a physical MAC. This allows |them to create virtual HBA devices that can request IP addresses from |DHCP. The virtual MAC helps routers and switches find the VM when its |instantiated or transported to another rack or facility. | |I'm reconsidered my past position on what's relegated to fabric in lieu |of a more comprehensive definition of IaaS. | |Lets look at some provider models: |1) A provider has hard iron that they physically provision for a |customer ( the dedicated hw model/ no sharing of anything) |2) A provider has pooled iron that they logically provision (fixed |resources/dedicated hw) specific for a customer ( the LPAR model). This |includes blades, minis, 100 cpu racks. |3) A provider has pooled iron that shared resource provisioning occurs |across customers ( the dynamic model). | |Irrespective of how the provider model fulfills its services, each are |providing specific items: CPUs, memory, network adapters, storage HBAs, |raw disk, filers, networks, VPNs, load balancers, web caches, name |servers, edge firewalls, etc... | |In the first case --- physical partitioning providers, the |infrastructure is hard iron and no doubt fabric. In the second two |models, LPAR and VM, all of the servers may be partially or completely |visualized. We need to address what this really means for the both the |providers and the consumers. | |Providers have a pool of resources they provision for each customer. I |assume each set of resources would/can be organized into one or more |federated accounts. Federations can be further subdivided into |administrative resources groups (zones). Each federation is logically |isolated from all other accounts for security and privacy constraints |and possibly quality agreements. The quality, availability, |responsiveness, besides types of services offered are several ways |providers differentiate themselves. | |Consumers receiving federated pool of resources, can administer them |according to their IT and business requirements. The administration can |include fire walling internal to the federation, VPN connections between |federations and zones, and balancing external workload across multiple |applications servers, Essentially, executing the same organizational and |administrative tasks occurring in private data centers. | |Unless there are hard requirements for physical isolation or dedicated |hardware, consumers will not care whether their infrastructure is |physically partitioned, implemented as LPARs, floating VMs or how |closely services are linked to fabric resources.. Consumers will expect |or require certain levels of quality from their service.. | |Bottom line: |Consumer services are defined by the providers; not all providers offer |the same services; and how a provider implements of their services, as |far as occi concerns, are unrelated to their service offerings. | |IMO, I don't think we can exclude cloud service providers because their |services are too "close" to the fabric. We need to include virtualized |hardware parameters like MACs as well as other infrastructure services |including DNS, firewalls and VPNs. | |In the world, there are going to be varying degrees of compatibility |betweens cloud provider technologies and service offerings. Some |differences can be easily be worked around, while other may be |irreconcilable; while all supporting and implementing occi. | |For example, virtual MACs are a hard reality and a critical attribute |for some providers. Even though they are not required by all providers, |it may not be a good idea to exclude them. In this case, the OCCI can |accommodate both type of providers by acting as a superset for network |adapter configurations. A provider not requiring a MAC address for their |operations can ignored the parameter. | |The idea that ALL occi cloud providers will be 100% inter-operating in |the face of differentiated (missing or incompatible) service offering |is unrealistic. For example, if a consumer has an application requiring |infrastructure provided load balancing services, they cannot engage a |provider not offering those services. The OCCI cannot reconcile |providers with incompatible infrastructures. In this example, the OCCI |can only provide a vehicle for the consumer to assess the capabilities |of a provider. | |Reiterating, I think we need to include more virtualized services and |vituralized hardware configurations. | |lemme get a few more cups of coffee... | |-gary | | | | |Sam Johnston wrote: |> On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com |> <mailto:garymazzaferro@gmail.com>> wrote: |> |> The question is: " Do operating systems belong in IaaS or PaaS. " |> |> |> Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, |> etc. you're venturing well into the underlying hardware fabric which |> is ultimately someone else's problem - I don't see any of these things |> appearing in current IaaS APIs[1]. |> |> Basically think of infrastructure services as everything up to the |> operating system interface (be that an API, CLI or a GUI). |> |> Platform services (PaaS) on the other hand include [most of] the |> solution stack... any app servers, databases, script/bytecode |> interpreters, etc. - think LAMP. You can just take your app and use it |> (in many was like it were a virtual machine - which is why the next |> step for us will be a small one). |> |> Software services (SaaS) then add the application itself. |> |> OCCI is most definitely IaaS. |> |> Sam |> |> 1. That is not to say they're not important - they are, particularly |> for "I can't believe it's not cloud" moreso than public cloud, but if |> they appear in OCCI they'll be optional. |> | |_______________________________________________ |occi-wg mailing list |occi-wg@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg
Krishna Sankar (ksankar) wrote:
Gary, Couple of points:
|provider not offering those services. The OCCI cannot reconcile |providers with incompatible infrastructures. In this example, the OCCI |can only provide a vehicle for the consumer to assess the capabilities |of a provider. <KS> We only provide interfaces et al. But it is not binary - folks can offer a subset or superset of capabilities </KS>
Sorry, just me getting ahead of the pack... There is a procedural aspect and best practices & techniques: "a how to guide". Someone/group will have to do a base implementation at sometime. Look at the source code provided by Sam Johnston..
|Reiterating, I think we need to include more virtualized services and |virtualized hardware configurations. <KS> I thought that is what we are doing ... because, underneath the instances can handle the specification in a multitude of ways and we are not prescriptive of any instantiation ... </KS>
Well, I am very uncomfortable by limited definition of IaaS capabilities. Think I can go out on a limb and say everyone participating in this group has the same intentions, yet details may be different. My concern is a very "nuts 'n bolts" problem. We don't have anything nailed down in terms of capabilities and features translated to hard attributes. Not yet anyway. In the past I had advocated for pushing some items out of scope, but after "hands on" evaluating different technologies, I've reconsidered my position nearly 180 degrees. The reversal is due partly to the technical feasibility of achieving interoperability and having a better understanding of underlying technologies. For example, the MAC address issue. I suggested that it should not be included as a core IaaS feature. I also noticed a few providers required MAC addresses to be set or top be provisioned. I though that was a little more than coincidental and perused working with VMs that used/required MAC addressees. After working with different VMs (eventually focusing on xVM) that relied on MAC addresses and other features, I reversed my position. In this case, the MAC attribute that seemed trivial, impacted the operation of the VM with far reaching effects. We need to tread cautiously before we remove attributes, services and other informations.
|lemme get a few more cups of coffee... <KS> Good idea ... am going to get some tea and will be back in a few ... too many discussions internally and externally on this ... need more juice ...</KS>
Yeah, but discussion is a way we can help get it right. :)
Cheers <k/>
|-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Gary Mazz |Sent: Sunday, June 14, 2009 9:53 AM |To: Sam Johnston |Cc: occi-wg@ogf.org |Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? | | |I was on the same wavelength as you are until about a 3 days ago, I was |getting xVM working on opensolaris. xVM para-virtualization has a |concept of a virtual MAC address not tied to a physical MAC. This allows |them to create virtual HBA devices that can request IP addresses from |DHCP. The virtual MAC helps routers and switches find the VM when its |instantiated or transported to another rack or facility. | |I'm reconsidered my past position on what's relegated to fabric in lieu |of a more comprehensive definition of IaaS. | |Lets look at some provider models: |1) A provider has hard iron that they physically provision for a |customer ( the dedicated hw model/ no sharing of anything) |2) A provider has pooled iron that they logically provision (fixed |resources/dedicated hw) specific for a customer ( the LPAR model). This |includes blades, minis, 100 cpu racks. |3) A provider has pooled iron that shared resource provisioning occurs |across customers ( the dynamic model). | |Irrespective of how the provider model fulfills its services, each are |providing specific items: CPUs, memory, network adapters, storage HBAs, |raw disk, filers, networks, VPNs, load balancers, web caches, name |servers, edge firewalls, etc... | |In the first case --- physical partitioning providers, the |infrastructure is hard iron and no doubt fabric. In the second two |models, LPAR and VM, all of the servers may be partially or completely |visualized. We need to address what this really means for the both the |providers and the consumers. | |Providers have a pool of resources they provision for each customer. I |assume each set of resources would/can be organized into one or more |federated accounts. Federations can be further subdivided into |administrative resources groups (zones). Each federation is logically |isolated from all other accounts for security and privacy constraints |and possibly quality agreements. The quality, availability, |responsiveness, besides types of services offered are several ways |providers differentiate themselves. | |Consumers receiving federated pool of resources, can administer them |according to their IT and business requirements. The administration can |include fire walling internal to the federation, VPN connections between |federations and zones, and balancing external workload across multiple |applications servers, Essentially, executing the same organizational and |administrative tasks occurring in private data centers. | |Unless there are hard requirements for physical isolation or dedicated |hardware, consumers will not care whether their infrastructure is |physically partitioned, implemented as LPARs, floating VMs or how |closely services are linked to fabric resources.. Consumers will expect |or require certain levels of quality from their service.. | |Bottom line: |Consumer services are defined by the providers; not all providers offer |the same services; and how a provider implements of their services, as |far as occi concerns, are unrelated to their service offerings. | |IMO, I don't think we can exclude cloud service providers because their |services are too "close" to the fabric. We need to include virtualized |hardware parameters like MACs as well as other infrastructure services |including DNS, firewalls and VPNs. | |In the world, there are going to be varying degrees of compatibility |betweens cloud provider technologies and service offerings. Some |differences can be easily be worked around, while other may be |irreconcilable; while all supporting and implementing occi. | |For example, virtual MACs are a hard reality and a critical attribute |for some providers. Even though they are not required by all providers, |it may not be a good idea to exclude them. In this case, the OCCI can |accommodate both type of providers by acting as a superset for network |adapter configurations. A provider not requiring a MAC address for their |operations can ignored the parameter. | |The idea that ALL occi cloud providers will be 100% inter-operating in |the face of differentiated (missing or incompatible) service offering |is unrealistic. For example, if a consumer has an application requiring |infrastructure provided load balancing services, they cannot engage a |provider not offering those services. The OCCI cannot reconcile |providers with incompatible infrastructures. In this example, the OCCI |can only provide a vehicle for the consumer to assess the capabilities |of a provider. | |Reiterating, I think we need to include more virtualized services and |vituralized hardware configurations. | |lemme get a few more cups of coffee... | |-gary | | | | |Sam Johnston wrote: |> On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com |> <mailto:garymazzaferro@gmail.com>> wrote: |> |> The question is: " Do operating systems belong in IaaS or PaaS. " |> |> |> Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, |> etc. you're venturing well into the underlying hardware fabric which |> is ultimately someone else's problem - I don't see any of these things |> appearing in current IaaS APIs[1]. |> |> Basically think of infrastructure services as everything up to the |> operating system interface (be that an API, CLI or a GUI). |> |> Platform services (PaaS) on the other hand include [most of] the |> solution stack... any app servers, databases, script/bytecode |> interpreters, etc. - think LAMP. You can just take your app and use it |> (in many was like it were a virtual machine - which is why the next |> step for us will be a small one). |> |> Software services (SaaS) then add the application itself. |> |> OCCI is most definitely IaaS. |> |> Sam |> |> 1. That is not to say they're not important - they are, particularly |> for "I can't believe it's not cloud" moreso than public cloud, but if |> they appear in OCCI they'll be optional. |> | |_______________________________________________ |occi-wg mailing list |occi-wg@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg
On this rare occasion (;o)), I fully agree with Sam. The "I" in IaaS includes compute, storage and network resources and the "drivers" thereof - which means domain managers with appropriate interface to provision, configure, monitor and meter them ... Cheers <k/> From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Sunday, June 14, 2009 6:45 AM To: Gary Mazz Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro@gmail.com> wrote: The question is: " Do operating systems belong in IaaS or PaaS. " Definitely IaaS. When you start talking about MAC addresses, VLAN IDs, etc. you're venturing well into the underlying hardware fabric which is ultimately someone else's problem - I don't see any of these things appearing in current IaaS APIs[1]. Basically think of infrastructure services as everything up to the operating system interface (be that an API, CLI or a GUI). Platform services (PaaS) on the other hand include [most of] the solution stack... any app servers, databases, script/bytecode interpreters, etc. - think LAMP. You can just take your app and use it (in many was like it were a virtual machine - which is why the next step for us will be a small one). Software services (SaaS) then add the application itself. OCCI is most definitely IaaS. Sam 1. That is not to say they're not important - they are, particularly for "I can't believe it's not cloud" moreso than public cloud, but if they appear in OCCI they'll be optional.
On Jun 14, 2009, at 6:35 AM, Gary Mazz wrote:
Sam Johnston's timely IaaS feature matrix brings up some interesting issues, one in particular, what are the specific features that can be included in an IaaS.
Many of the IaaS provider are also providing one or more operating systems while other are providing closer to bare metal. Is the OS part of the Infrastructure or part of the Platform ?
IMO IaaS is about flexibility and thus should provide bare metal (or virtual bare metal) so that customers can use any OS they choose. OVF seems to require this, since an OVF image can contain any OS; thus if your IaaS claims to support OVF then you should be able to run *any* OVF image containing *any* OS. I think this also requires full virtualization since paravirtualization is neither standardized nor widespread. IaaS providers can provide optional prebuilt OS images, but it shouldn't be part of the infrastructure. Wes Felter - wesley@felter.org - http://felter.org/wesley/
Wes, Good point and you are right - IaaS will offer different OS layers. But the question is "Is that OS layer (and associated attributes) part of IaaS" and the answer is Yes. The OS can be pre-built by the Cloud Service Provider, it could be a reference (local or remote) in an OVF manifest, it could be a binary disk image file in an OVF parcel and it could be a multi-tiered application in an OVF parcel - which is more interesting because it will have interesting internal firewall rules, load balancing attributes et al. So including the OS layer in the IaaS does not (and should not) preclude selection of the OS et al. Cheers <k/> |-----Original Message----- |From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf |Of Wes Felter |Sent: Sunday, June 14, 2009 1:44 PM |To: occi-wg@ogf.org |Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? | |On Jun 14, 2009, at 6:35 AM, Gary Mazz wrote: | |> Sam Johnston's timely IaaS feature matrix brings up some interesting |> issues, one in particular, what are the specific features that can be |> included in an IaaS. |> |> Many of the IaaS provider are also providing one or more operating |> systems while other are providing closer to bare metal. Is the OS part |> of the Infrastructure or part of the Platform ? | |IMO IaaS is about flexibility and thus should provide bare metal (or |virtual bare metal) so that customers can use any OS they choose. OVF |seems to require this, since an OVF image can contain any OS; thus if |your IaaS claims to support OVF then you should be able to run *any* |OVF image containing *any* OS. I think this also requires full |virtualization since paravirtualization is neither standardized nor |widespread. | |IaaS providers can provide optional prebuilt OS images, but it |shouldn't be part of the infrastructure. | |Wes Felter - wesley@felter.org - http://felter.org/wesley/ | |_______________________________________________ |occi-wg mailing list |occi-wg@ogf.org |http://www.ogf.org/mailman/listinfo/occi-wg
Wes, Unfortunately, we're very far from this. There are three different types of hypervisor: software (VMware), hardware (Xen, et al), and paravirtualized (VMware + VMI, Xen in paravirt mode, etc.). Despite the fact that folks claim that unmodified VMs can run under Xen, in the real world *everyone* provides customized network and disk drivers for the guest OS because the performance is abysmal. These are 'paravirtualized drivers', which is why the performance can be so dramatically affected. Unfortunately, there isn't a standard of any kind, so you'll find that the paravirt drivers for disk drives for the SLES Xen hypervisor will have problems running under the RHEL Xen hypervisor and vice versa. The same kind of issue holds true for VMware where you just won't see acceptable performance unless the VMware drivers and tools are installed. Now, you could say: "Well, folks will just have a performance hit" and I would agree if we were talking about inside the firewall, but the reality is that in public clouds folks are very eager to get the maximum performance from a single instance in order to maximize their dollars spent. So you are quickly in a situation where ignoring the OS isn't feasible. Even though OVF doesn't provide for this, it SHOULD. It's an oversight on the part of VMware and Xen. Once providers start allowing uploading of arbitrary VM images, they are also going to need what OS is in the image package so that they can dynamically install the correct paravirt drivers for the hypervisor they are using. 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. --Randy On Jun 14, 2009, at 1:44 PM, Wes Felter wrote:
On Jun 14, 2009, at 6:35 AM, Gary Mazz wrote:
Sam Johnston's timely IaaS feature matrix brings up some interesting issues, one in particular, what are the specific features that can be included in an IaaS.
Many of the IaaS provider are also providing one or more operating systems while other are providing closer to bare metal. Is the OS part of the Infrastructure or part of the Platform ?
IMO IaaS is about flexibility and thus should provide bare metal (or virtual bare metal) so that customers can use any OS they choose. OVF seems to require this, since an OVF image can contain any OS; thus if your IaaS claims to support OVF then you should be able to run *any* OVF image containing *any* OS. I think this also requires full virtualization since paravirtualization is neither standardized nor widespread.
IaaS providers can provide optional prebuilt OS images, but it shouldn't be part of the infrastructure.
Wes Felter - wesley@felter.org - http://felter.org/wesley/
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Randy Bias, Cloud Strategist +1 (415) 939-8507 [m], randyb@neotactics.com BLOG: http://cloudscaling.com
On Mon, Jun 15, 2009 at 5:05 AM, Randy Bias <randyb@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
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. On Jun 14, 2009, at 8:38 PM, Sam Johnston wrote:
On Mon, Jun 15, 2009 at 5:05 AM, Randy Bias <randyb@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@neotactics.com BLOG: http://cloudscaling.com
On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@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@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@neotactics.comBLOG: http://cloudscaling.com
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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Thursday, June 18, 2009 4:20 AM To: Randy Bias Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@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@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@neotactics.com BLOG: http://cloudscaling.com
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@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@ogf.org [mailto:occi-wg-bounces@ogf.org<occi-wg-bounces@ogf.org>] *On Behalf Of *Sam Johnston *Sent:* Thursday, June 18, 2009 4:20 AM *To:* Randy Bias *Cc:* occi-wg@ogf.org *Subject:* Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@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@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@neotactics.com
BLOG: http://cloudscaling.com
------------------------------
_______________________________________________ occi-wg mailing listocci-wg@ogf.orghttp://www.ogf.org/mailman/listinfo/occi-wg
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@samj.net] Sent: Saturday, June 20, 2009 10:21 AM To: Michael Behrens Cc: Krishna Sankar (ksankar); Randy Bias; occi-wg@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@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Thursday, June 18, 2009 4:20 AM To: Randy Bias Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@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@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@neotactics.com BLOG: http://cloudscaling.com ________________________________ _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
k, The occi is not inventing new technology like OVF, DMTF, SNIA or any other "special" agenda/SDO groups that focus on a specific vendor's or a specific technological solution. We are aggregating the work of others, you can hardly call that NIH syndrome. I believe we collectively have shown a desire to have a simpler interface, hence the demand and consensus for a RESTful interface pattern. We haven't completed the analysis of OVF to the other API attributes to make a judgment call to consider its capabilities for our effort. There are features or lack of features in OVF that currently alienate some providers. I'm sure VMWare would be very happy to be able to say the cloud interoperability spec is based on their technology. Just let me know when the occi press release comes out and says that. I'd like to purchase a bunch of EMC/VMWare stock prior to the press release. And, complexity does normally increase over time due to a wide variety of issue. This commonly occur due the the lack of proper requirements aka "the stuff we don't know - we don't know" and hurrying though the process, dropping stuff through the cracks. Its all good... -gary Krishna Sankar (ksankar) 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@samj.net] *Sent:* Saturday, June 20, 2009 10:21 AM *To:* Michael Behrens *Cc:* Krishna Sankar (ksankar); Randy Bias; occi-wg@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@r2ad.com <mailto:michael.behrens@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@ogf.org <mailto:occi-wg-bounces@ogf.org> [mailto:occi-wg-bounces@ogf.org] *On Behalf Of *Sam Johnston *Sent:* Thursday, June 18, 2009 4:20 AM *To:* Randy Bias *Cc:* occi-wg@ogf.org <mailto:occi-wg@ogf.org> *Subject:* Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@neotactics.com <mailto:randyb@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@neotactics.com <mailto:randyb@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@neotactics.com <mailto:randyb@neotactics.com>
BLOG: http://cloudscaling.com
------------------------------------------------------------------------
_______________________________________________ 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 http://www.ogf.org/mailman/listinfo/occi-wg
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@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@samj.net] *Sent:* Saturday, June 20, 2009 10:21 AM *To:* Michael Behrens *Cc:* Krishna Sankar (ksankar); Randy Bias; occi-wg@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@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@ogf.org [mailto:occi-wg-bounces@ogf.org<occi-wg-bounces@ogf.org>] *On Behalf Of *Sam Johnston *Sent:* Thursday, June 18, 2009 4:20 AM *To:* Randy Bias *Cc:* occi-wg@ogf.org *Subject:* Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@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@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@neotactics.com
BLOG: http://cloudscaling.com
------------------------------
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
Krishna, I've been looking further into the current state of play with OVF support and doing some tests with various products. I found an interesting InfoWeek article including the views of one of my former colleagues at Citrix: "Crosby: Walk The Walk, Yes, But Not Down The OVF Path<http://www.informationweek.com/blog/main/archives/2008/10/crosby_walk_the.html> ". Which brings me back to my original Time To Walk The Walk<http://www.informationweek.com/blog/main/archives/2008/10/virtualization_9.html>point. If we now have a neutral export/import format, why can't we have a
neutral runtime format that everyone could adhere to, saving virtualization customers tons of headaches? OVF isn't it, I now understand. But what will be?
So for runtime formats we've got: - VMware using key-value pairs (VMX) which spills over into XML - Sun VirtualBox using a home-grown OVF-style XML format - Microsoft Virtual Server and Virtual PC using another home-grown XML format - Citrix XenServer using a simple INI style key-value pair (xmdomain.cfg<http://linux.die.net/man/5/xmdomain.cfg> ) The most successful runtime formats by far then are the flat text formats, though for safety and extensibility it makes sense to have namespaces ala VMX: usb.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.generatedAddress = "00:0c:29:cd:98:8f" That is to say that we may want to (somewhat independently of the OCCI protocol itself) standardise a runtime descriptor format which allows us to describe basic infrastructure - probably only the things that are currently exposed by IaaS offerings like cpu cores, memory size, etc. Sam On Sun, Jun 21, 2009 at 1:12 PM, Sam Johnston <samj@samj.net> wrote:
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@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@samj.net] *Sent:* Saturday, June 20, 2009 10:21 AM *To:* Michael Behrens *Cc:* Krishna Sankar (ksankar); Randy Bias; occi-wg@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@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@ogf.org [mailto:occi-wg-bounces@ogf.org<occi-wg-bounces@ogf.org>] *On Behalf Of *Sam Johnston *Sent:* Thursday, June 18, 2009 4:20 AM *To:* Randy Bias *Cc:* occi-wg@ogf.org *Subject:* Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@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@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@neotactics.com
BLOG: http://cloudscaling.com
------------------------------
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
Sam,
That is to say that we may want to (somewhat independently of the OCCI protocol itself) standardize a runtime descriptor format which allows us to describe basic infrastructure - probably only the things that are currently exposed by IaaS offerings like cpu cores, memory size, etc. <KS> Agreed. Good idea. We should have a vocabulary for the basic infrastructure elements exposed by IaaS; probably the actions come later.
Only point I would make is that, if we could morph OVF we should do that, because there is some synergy. But if there are valid reasons for not doing so, that is fine; in any case a vocabulary is needed. </KS> Cheers <k/> From: Sam Johnston [mailto:samj@samj.net] Sent: Tuesday, June 30, 2009 11:09 AM To: Krishna Sankar (ksankar) Cc: Michael Behrens; Randy Bias; occi-wg@ogf.org Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? Krishna, I've been looking further into the current state of play with OVF support and doing some tests with various products. I found an interesting InfoWeek article including the views of one of my former colleagues at Citrix: "Crosby: Walk The Walk, Yes, But Not Down The OVF Path". Which brings me back to my original Time To Walk The Walk point. If we now have a neutral export/import format, why can't we have a neutral runtime format that everyone could adhere to, saving virtualization customers tons of headaches? OVF isn't it, I now understand. But what will be? So for runtime formats we've got: * VMware using key-value pairs (VMX) which spills over into XML * Sun VirtualBox using a home-grown OVF-style XML format * Microsoft Virtual Server and Virtual PC using another home-grown XML format * Citrix XenServer using a simple INI style key-value pair (xmdomain.cfg) The most successful runtime formats by far then are the flat text formats, though for safety and extensibility it makes sense to have namespaces ala VMX: usb.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.generatedAddress = "00:0c:29:cd:98:8f" That is to say that we may want to (somewhat independently of the OCCI protocol itself) standardise a runtime descriptor format which allows us to describe basic infrastructure - probably only the things that are currently exposed by IaaS offerings like cpu cores, memory size, etc. Sam On Sun, Jun 21, 2009 at 1:12 PM, Sam Johnston <samj@samj.net> wrote: 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) and IBM 's WebSphere CloudBurst Appliance (per IBM CloudBurst runs on ESXi) as these products are based on VMware, which as of the latest release now has full support for OVF (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?" 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) 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 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, 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@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@samj.net] Sent: Saturday, June 20, 2009 10:21 AM To: Michael Behrens Cc: Krishna Sankar (ksankar); Randy Bias; occi-wg@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@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Thursday, June 18, 2009 4:20 AM To: Randy Bias Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ? On Thu, Jun 18, 2009 at 8:32 AM, Randy Bias <randyb@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@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@neotactics.com BLOG: http://cloudscaling.com ________________________________________ _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (9)
-
André Brinkmann -
André Brinkmann -
Edmonds, AndrewX -
Gary Mazz -
Krishna Sankar (ksankar) -
Michael Behrens -
Randy Bias -
Sam Johnston -
Wes Felter