[occi-wg] Opinion Poll: IaaS or PaaS ?

[Gary Mazz]

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 at ogf.org [mailto:occi-wg-bounces at ogf.org] On
> Behalf
> |Of Gary Mazz
> |Sent: Sunday, June 14, 2009 9:53 AM
> |To: Sam Johnston
> |Cc: occi-wg at 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 at gmail.com
> |> <mailto:garymazzaferro at 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 at ogf.org
> |http://www.ogf.org/mailman/listinfo/occi-wg
>
>