Moved to DCIFed mailing list On 4/5/2011 7:28 AM, Sill, Alan wrote:
To facilitate this, we should ensure that all relevant parties are subscribed to that list.
To summarize: We need a WG home for IaaSCIP; DCIFed has been suggested as an alternative to spinning up a new group, which is still possible; the OCCI-WG list is probably not the best one to discuss this.
Any objections to moving this discussion to the DCIFed-WG list? If this is ok, Gary and Andre, can you double-check the current subscribers and advise at least Steven, David, and others who have participated in this discussion so far whether they are subscribed? (Just a suggestion.)
Thanks, Alan
On Apr 5, 2011, at 7:20 AM, "Andy Edmonds"<andy@edmonds.be<mailto:andy@edmonds.be>> wrote:
Wouldn't it be better if these mails are moved off to the DCI-Fed mailing list perhaps? <mailto:dcifed-wg@ogf.org>dcifed-wg@ogf.org<mailto:dcifed-wg@ogf.org>
Andy <http://andy.edmonds.be>andy.edmonds.be<http://andy.edmonds.be>
On Tue, Apr 5, 2011 at 12:05, Gary Mazz<<mailto:garymazzaferro@gmail.com>garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>> wrote: Thanks... They didn't show up when I looked at the email... Sometimes attachments show up late, not sure why..
After reviewing the slides... I think we will have to make changes to the charter.
I am a little concerned about certain aspects of the presentation.
Profiles require a taxonomy, one that doesn't really exist today. Profiles also indicate levels of interoperability, we need see how this ties into other initiatives.
OVF, although OVF is moving toward standardization, it recommends a proprietary disk image format. I have a hard time believing that standardizing a proprietary image format will pass ISO's muster, I couldn't support it for OGF with the VMWare proprietary technology in there..
Authentication and Authorization, and the definition of SAML, although SAML is on the worldmap today, we need to be cautious about other Attribute Based Authorization Control as well as legacy RBAC schemes. AA even has its own taxonomy associated with it.
Logging, traceability, billing information and their impacts on privacy and plausible deniability is another can of worms all on its own..
My concern here it there is much more in IAASCIP that in the DCIFed charter, and may not be achievable with out a very large influx of contribution. We will have to carefully pick and choose what we will adopt. Or be very very clever about how we approach the interfaces. I don't think we can get away with defining a "bunch of apis and protocols" This will all have to be consistent or else it will just be a mess.
I do like the idea of tying use cases to profiles.. But, we need to be careful there aren't other initiatives already engaged, like the US Govt. FedRAMP doc. Its a security profile for GSA providers.
-g
On 4/5/2011 4:05 AM,<mailto:alexander.papaspyrou@tu-dortmund.de> alexander.papaspyrou@tu-dortmund.de<mailto:alexander.papaspyrou@tu-dortmund.de> wrote: Hey Gary,
I sent around a slide deck yesterday -- that is basically it. I guess David or Steven (or both) have minutes, but I am not sure. Everything else we need to elicit from the two via email discussion...
Best, Alexander
Am 05.04.2011 um 10:49 schrieb Gary Mazz:
Hi, Do you have the papers for IAASCIP ? gary
On 4/4/2011 6:47 AM,<mailto:alexander.papaspyrou@tu-dortmund.de> alexander.papaspyrou@tu-dortmund.de<mailto:alexander.papaspyrou@tu-dortmund.de> wrote: Nice discussion, guys. I think Gary makes a fair point here: the NIST definition is sort of strict in terms of what is called IaaS, and most probably anything that is slightly more useful than bare metal without OS and VMM/Hypervisor drivers will fall into PaaS (although this kind of separation is a bit awkward to me).
But (insert deeper voice here) as a chair of the group (ahem), I need to bring the discussion back to the original topic ;-)
We need to recharter slightly to accommodate the needs from the IaaSCIP people, most likely getting a bit broader regarding "resource leasing". Whether this is considered IaaS or PaaS is, for the purpose of the group charter, irrelevant IMHO.
So, it would be great if I could get a few suggestions on rephrasing (everyone, please), and a timeline proposal (Steven, David).
Best, Alexander
Am 30.03.2011 um 23:07 schrieb Andy Edmonds:
:-) Agreed
Regards from an IaaS believer :-),
Andy <http://andy.edmonds.be>andy.edmonds.be<http://andy.edmonds.be>
On Wed, Mar 30, 2011 at 21:45, Andre Merzky<<mailto:andre@merzky.net>andre@merzky.net<mailto:andre@merzky.net>> wrote: On Wed, Mar 30, 2011 at 7:30 PM, Andy Edmonds<<mailto:andy@edmonds.be>andy@edmonds.be<mailto:andy@edmonds.be>> wrote: Hmmm - I wouldn't agree either that IaaS no longer exists. Even if no IaaS provider exists right now, that does not mean that there won't ever be a IaaS provider again. Also, it seems useful to me to well-define IaaS, even if nobody would ever provide clean IaaS offerings, simply for distinguishing other *aaS levels from IaaS. Like, you can't sensibly say 'there is no IaaS provider' withough defining IaaS ;-)
My $0.02,
Andre.
On reading the NIST definition of IaaS it says it is: "The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls)." Clearly, OS is included in the IaaS domain as defined by NIST. Likewise the close relationship of OS and IaaS is clearly marked out in the current NIST Standards Roadmap (pre-9th) document. It's also this close relationship as to why the OS template concept was included in the OCCI Infrastructure document. What is apparent however is that the presence of pure IaaS providers is certainly less today, given that further value (to the business) is gained by offering higher level services (e.g. those that fall into the PaaS category). I certainly think that some very interesting, real and usable output can come from the group, especially given the excellent relationships we now have with SNIA and DMTF. For those that are not aware there will be a very appropriate set of meetings held in Boulder, Colorado in May. It's open to all so if you can make it your experience and input would be most appreciated. More details can be found up on the OCCI site [1] Regards, Andy <http://andy.edmonds.be>andy.edmonds.be<http://andy.edmonds.be>
[1]<http://occi-wg.org/2011/03/15/occi-the-cloud-sdo-alliance-symposium/> http://occi-wg.org/2011/03/15/occi-the-cloud-sdo-alliance-symposium/
On Tue, Mar 29, 2011 at 19:53, Gary Mazz<<mailto:garymazzaferro@gmail.com>garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>> wrote: Agreed with most of what you said, except for IAAS.
Let me explain, IAAS and PAAS as defined by NIST is precise. IAAS is bare metal vitalization while PAAS includes Operating systems as well as other services. Since most providers require or provide OS' tuned/modified for their infrastructure, they fall into the PAAS bucket. If we want to keep the IAAS term around, we are going to have to change the NIST definition. I proposed to change it in January to align it with current provider offerings, but NIST was mandated to keep the current definitions until after the April milestone. Even private cloud configurations using VMware, XEN, Hyper-V all require specialized versions of drivers... Once that occurs, it is no longer IAAS...
I think we all agree we need to move to a profiling systems. I had already proposed the idea to the Reference Architecture and Taxonomy wg. It was not met overwhelming disagreement, which is a good first step. Profiles will require a taxonomy, enough to at least characterize the service offerings. They (Reference Architecture and Taxonomy wg) are willing to explore the idea after the April workshop.
-g
On 3/29/2011 10:06 AM, Alan Sill wrote: From my point of view, the only thing that cloud services brought to grids that we were not already doing was through the introduction of the IaaS layer. Everything else was already available, and the only new components we are looking at adding have to do with addition of RESTful protocols to the interface and control layers. That does not require invention of new levels.
I think it may be premature, though, by far to say that IaaS is "on its way out" as a paradigm, or is evolving to simply rebranding or PaaS components. I personally do not not know how much buy-in exists for that point of view right now in the community at large.
From my point of view, anything that the group wants to call this profile is OK with me. It really bridges across many layers and is the first step towards what one might more rightfully call a "Cloud Basic Profile."
The group is not ready to bite off such a large chunk of work, though, and presented in Taiwan a model for staged evolution of a profile - IaaSCIP - over time to achieve an increasing set of capabilities. It seemed to be important to start at a manageable scale, and I wholeheartedly support the basic infrastructure diagram that was presented by David and Steven at the BOF and informally in other settings at OGF 31. I think it is more important that the profile be available and have practical impact than worrying over details as to what it is called.
In the long run, I do think that work towards a basic cloud profile of standards for RESTful interfaces to infrastructure, platform and service controls as well as moving of data will be important and useful.
Alan
On Mar 29, 2011, at 10:38 AM, Gary Mazz wrote:
Hi,
I think Alan knows... IAAS, really no longer exists, as defined by NIST. There are 3 options; redefine, mark as obsolete, and removal from the model. Since the current model and definitions are strategic, and the market has evolved passed the current definition there is little reason to keep it around, other than product branding.
-g
On 3/29/2011 4:19 AM,<mailto:alexander.papaspyrou@tu-dortmund.de> alexander.papaspyrou@tu-dortmund.de<mailto:alexander.papaspyrou@tu-dortmund.de> wrote: Hey Gary,
you should speak to Alan Sill (<<mailto:alan.sill@ttu.edu>alan.sill@ttu.edu<mailto:alan.sill@ttu.edu>>) on that topic, since he was and is quite active in promoting OCCI work within NIST SAJACC.
Best, Alexander
Am 25.03.2011 um 18:28 schrieb Gary Mazz:
Hi,
I though there was agreement :-)
BTW, I have already proposed to NIST to drop IAAS from their work. I feel today that the market offering has evolved over the last two years, we are hard pressed to find providers supplying IAAS. Most providers with the offering are now providing PAAS branded as IAAS. NIST will examine dropping IAAS after the April workshop.
cheers, gary
On 3/25/2011 11:13 AM, Andre Merzky wrote: On Fri, Mar 25, 2011 at 3:34 PM,<<mailto:alexander.papaspyrou@tu-dortmund.de>alexander.papaspyrou@tu-dortmund.de<mailto:alexander.papaspyrou@tu-dortmund.de>> wrote: Folks,
I discussed our idea to do the IaaSCIP (Gary, Andy, see the session information online; Steven, David, please send around some details on this) stuff within DCIfed with our AD, Andre Merzky (see cc:), and he is very positive about this. Just to confirm: when the BoF organizers and the DCI-Fed WG are all in agreement, I would consider the integration of IaaSCIP's goals into the WG's milestones a 'simple' adjustment of the WG's scope, due to new and relevant use cases. FWIW, Richard is fine with this procedure as well.
Cheers, Andre.
To check the details and see whether things fit together as we would like them to, please find the current charter of DCIfed attached as PDF, or take a look online here:
Since we need to change the dates of the deliverables anyway, it shouldn't be too difficult to make small modifications to the text as well. OVerall, the use cases that David and Steven would like to address fit pretty well into the "Resource Leasing" use case (even the proposed specs to use overlap).
Please take a look and let me know how we should proceed.
Best, Alexander
Alan Sill, Ph.D Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU
==================================================================== : Alan Sill, Texas Tech University Office: Drane 162, MS 4-1167 : : e-mail:<mailto:Alan.Sill@ttu.edu> Alan.Sill@ttu.edu<mailto:Alan.Sill@ttu.edu> ph. 806-742-4350<tel:806-742-4350> fax 806-742-4358<tel:806-742-4358> : ====================================================================
-- So much time, so little to do... [Garfield]