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.