maybe I'm missing something, but if you don't want to run a recent API why should you expect to be able to run it with a recent release of nova? I think trying to support older and new versions at the same time would clip our wings, or at the very least add some nastiness to the code. If someone wants to run old API, they should have to run old openstack with it. If they want new openstack, they should run the new API. I do apologize if I am in fact missing something.<div>
<br></div><div>-tr3buchet<br><br><div class="gmail_quote">On Thu, Mar 3, 2011 at 9:05 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Brian Waldon wrote:<br>
> Currently, the Openstack API includes a Versions WSGI application. The<br>
> intended purpose is to detail all versions of the API that are reachable<br>
> by a client. Currently, it only supports "v1.0." As we move towards the<br>
> Cactus release, we need to add support for the new "v1.1" specification.<br>
> The intention of the Versions app seems to be to deploy multiple<br>
> versions of the OS API within the same codebase. Since these two<br>
> versions have significant differences, having to support each in the<br>
> same code seems unnatural.<br>
><br>
> With the existing approach, versioning could be accomplished multiple<br>
> ways: version-specific "if" statements, version-specific class<br>
> hierarchies, etc. I feel this is inelegant and could be accomplished a<br>
> much cleaner way. I propose we move the responsibilities of the Versions<br>
> app out of the nova codebase and into the hands of the operator of the<br>
> api endpoints. With this approach, the code would not unnecessarily<br>
> increase in complexity as more versions of the api are released. The<br>
> major drawback of this strategy is that each release of Openstack<br>
> Compute could support a single OS API version.<br>
<br>
</div>For the OpenStack API to grow a significant partner ecosystem, it seems<br>
important to me to support at least the recent versions of the API in<br>
new releases of Openstack Compute...<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>
</blockquote></div><br></div><PRE>
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@rackspace.com, and delete the original message.
Your cooperation is appreciated.
</PRE>