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