On Jan 8, 2011, at 9:47 AM, Sandy Walsh wrote:

> Hi!
> 
> I just read the EasyAPI BP and, from a technical perspective, seems rational 
> and sound. The challenge, of course, are the implications for the business 
> side of the house. I realize it doesn't make sense to strive for backward 
> compatibility to EC2/RS API's from EasyAPI, but perhaps the BP should discuss 
> what an API Bridge might look like so we can pull out the existing API 
> services and map them to EasyAPI?
> 

+1

I'd love for the blueprint to describe the API Bridge.


> Another point of consideration might be unimplemented features at the 
> hypervisor level being reflected in the public API. For example, we have 
> already added several features on the XenServer side that don't currently 
> have sister operations on the KVM side. Should these operations appear in the 
> public API? Or, should the choice of hypervisor cause the public API WADL to 
> change? Perhaps it's fine to simply tell a "stack" user "<Blah> feature is 
> not implemented for <Foo> hypervisor"?
> 

This is a perfect use case for API extensions.  The idea here is that features 
that all hypervisors can support are part of the core API.  Hypervisor specific 
features are written as extensions. Extensions are query-able, so you can 
programmatically detect which extensions are available in a particular 
deployment.  My thoughts are that yes, this would also cause the public API 
WADL to change, but there should still be an extension call that's easy to 
parse and gives an unambiguous indication that an extension is available 
without having to parse the WADL.  The call also points to documentation on the 
extension.

Are there features in Cloud Servers API V1.0 that can't be supported by all 
hypervisors?

-jOrGe W.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to