openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

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.