<br><br><div class="gmail_quote">On Sat, Jan 8, 2011 at 7:47 AM, Sandy Walsh <span dir="ltr"><<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi!<br>
<br>
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?<br>
<br></blockquote><div><br></div><div>Sure, I can add that more fully today, I touched on it a bit already in there but I can give a more detailed example.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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"?<br>
</blockquote><div><br></div><div>My initial gut response would be to make a method on compute, 'raw_hypervisor_call,' that forwards down a level to the hypervisor so that we can have access to individual low-level methods while people decide whether to add them more globally. Probably from there you make an additional api handle for the specific implementation, say XenAPI and register it at /xen/* and have it generate rpc calls to the 'raw_hypervisor_call' method.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Just some thoughts.<br>
<br>
-Sandy<br>
<br>
<br>
<br>
________________________________________<br>
From: openstack-bounces+sandy.walsh=<a href="http://rackspace.com" target="_blank">rackspace.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a> [openstack-bounces+sandy.walsh=<a href="http://rackspace.com" target="_blank">rackspace.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>] on behalf of Thierry Carrez [<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>]<br>
Sent: Wednesday, January 05, 2011 4:38 AM<br>
To: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
<div class="im">Subject: Re: [Openstack] [RFC] OpenStack API<br>
<br>
</div><div><div></div><div class="h5"><a href="mailto:ksankar@doubleclix.net">ksankar@doubleclix.net</a> wrote:<br>
> I have added a new blue print<br>
> <a href="https://blueprints.launchpad.net/nova/+spec/open-stack-api" target="_blank">https://blueprints.launchpad.net/nova/+spec/open-stack-api</a> and<br>
> associated wiki page to capture and make some progress.I have a<br>
> launchpad account from my Ubuntu days.<br>
<br>
Hey ksankar,<br>
<br>
We already have a blueprint to cover the Openstack API efforts for teh<br>
Bexar release at:<br>
<br>
<a href="https://blueprints.launchpad.net/nova/+spec/openstack-api-parity" target="_blank">https://blueprints.launchpad.net/nova/+spec/openstack-api-parity</a><br>
<br>
See previous threads in that list: The Openstack API (1.0) support<br>
already exists in the code, it is currently the Rackspace Cloud API.<br>
Version 1.1 of that API (in Cactus) should have an Openstack namespace<br>
and extensibility.<br>
<br>
> [...]<br>
> Developing an Open Stack Cloud System-level CLI might be a good start ...<br>
<br>
As part of the above spec, Sandy Walsh has a new python-cloudservers<br>
library (and accompanying cloudservers CLI tool) that, with adequate<br>
rebranding, should just be what you're looking for.<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
<br>
</div></div><div class="im">Confidentiality Notice: This e-mail message (including any attached or<br>
embedded documents) is intended for the exclusive and confidential use of the<br>
individual or entity to which this message is addressed, and unless otherwise<br>
expressly indicated, is confidential and privileged information of Rackspace.<br>
Any dissemination, distribution or copying of the enclosed material is prohibited.<br>
If you receive this transmission in error, please notify us immediately by e-mail<br>
at <a href="mailto:abuse@rackspace.com">abuse@rackspace.com</a>, and delete the original message.<br>
Your cooperation is appreciated.<br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>