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