[Capi-bof] Charter - last call for changes

[Edmonds, AndrewX]

Yes Sam, customer/client facing APIs are what I am referring to. And without respect to the WG charter, I agree on the notion (the “what” not “how”) of requesting a compute resource(s) of some kind via programmatic interaction. With respect to the actual charter if it is needed and it seems so according to David, then we need to be specific in the charter but then in further works (specification etc) we can be more generic and move from notions like “provisioning virtual machines” to “provisioning resources of a particular type”.  Any API that dictates how resources can be created, managed and destroyed must not include any specific hypervisor specifics and so on this aspect, I’d agree again with Sam.

I think if we are to be specific within the charter description then perhaps we move from referring to virtual machines to virtual resources, in that way we avoid introducing confusion with hypervisor technology to which virtual machines are tightly associated with.

Regarding what goes on inside the cloud or I guess more specifically in our case the infrastructure provider, I’d agree that we shouldn’t be concerned with that.

Andy

From: capi-bof-bounces at ogf.org [mailto:capi-bof-bounces at ogf.org] On Behalf Of Sam Johnston
Sent: 25 March 2009 09:57
To: David Snelling
Cc: Thijs Metsch; capi-bof
Subject: Re: [Capi-bof] Charter - last call for changes

On Wed, Mar 25, 2009 at 10:34 AM, David Snelling <David.Snelling at uk.fujitsu.com<mailto:David.Snelling at uk.fujitsu.com>> wrote:
So let's focus on VM, but leave extensibility in place so this spec could be used inside the cloud.

I think we all agree that what goes on inside the cloud is of absolutely no concern to us - Cisco's Unified Computing System is a great example of the type of innovation that will take place under the covers and as a consumer all I want is to get just enough resources to run my workload as efficiently as possible. It's worth mentioning that as an independent consultant (working with large eurpean enterprises) my view is predominately that of a consumer; like Alexis I don't have any associations with any product/provider that might restrict my view.

What Andy (if I understand well) and I are talking about is a consumer-facing cloud service that defines *what* is delivered without placing arbitrary (and thus far completely unjustified) restrictions on *how* it is delivered. For those of us already working in the not-too-distant future the VM is a necessary albeit temporary evil and a legacy that will with any luck be shed before too long.

For example, where I span a .Net product across Windows VMs today it is likely that I will be pushing it out to Azure tomorrow. The operating system is for most applications unnecessary cruft (with significant resource overhead) that still needs to be deployed and maintained, and the sooner it gets put out of its misery the better.

Given the rate of change in the industry at the moment it is not inconcievable that any VM-specific API started today could be obsolete by launch, and I have already demonstrated at least three providers who could benefit from this API if we shed the proposed restrictions now.

Sam
-------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/capi-bof/attachments/20090325/cfba5f01/attachment.html