<font face="arial" size="2"><p>While a middleware solution for the "limited" functionality would technically work, I think most of us would agree it should not be implemented as middleware. It can be done much more efficiently at the datastore level, especially with the introduction of "marker".</p>
<p> </p>
<p>As for shared_ip_groups, I wouldn't want to implement an essentially blank controller. I would just leave it out and not expose it through the router.</p>
<p> </p>
<p>While I do think we can make multiple versions live together in trunk, I would rather see the directory structure like the following. We would put the existing code in common/ and things like shared_ip_groups.py in v10 only. We would have a servers controller in all three folders, since they have common functionality but still some version-specific differences.</p>
<p> </p>
<p>/nova/api/openstack/common/</p>
<p>/nova/api/openstack/v10/</p>
<p>/nova/api/openstack/v11/</p>
<p> </p>
<p>Waldon</p>
<p> </p>
<p>-----Original Message-----<br />From: "Jay Pipes" <jaypipes@gmail.com><br />Sent: Friday, March 4, 2011 2:08pm<br />To: "Brian Waldon" <brian.waldon@rackspace.com><br />Cc: "Brian Lamar" <brian.lamar@rackspace.com>, "openstack@lists.launchpad.net" <openstack@lists.launchpad.net><br />Subject: Re: [Openstack] Multiple Versions in Openstack API<br /><br /></p>
<div id="SafeStyles1299266991">
<p>On Fri, Mar 4, 2011 at 1:33 PM, Brian Waldon <brian.waldon@rackspace.com> wrote:<br />> As Brian is temporarily out of the office, I'll answer for him. Here are a<br />> few (major-version) differences I see in the 1.1 spec:<br /><br />OK. Either Brian is good ;)<br /><br />> 1) marker keyword replaces offset for pagination (functionally different,<br />> not just a different name)<br /><br />OK. This would mean that the current<br />nova.api.openstack.common.limited() function should move to be instead<br />a middleware class, say,<br />nova.api.openstack.limits.v10.LimitMiddleware, and that we can make a<br />v11.LimitMiddleware for the new 1.1 functionally-different limiter.<br /><br />> 2) server addresses container structured differently<br /><br />This is easily solved in the code I showed. Simply implement the<br />index()/show()/details() method to return the different structure.<br /><br />> 3) all containers structured differently, now with links<br /><br />Again, this can be solved by implementing methods differently (using<br />object-method overrides in the child class).<br /><br />> 3) shared ip groups is removed<br /><br />So, the shared IP methods of the 1.0 API are all in<br />/nova/api/openstack/shared_ip_groups.py. We would do the following:<br /><br />* bzr mv nova/api/openstack/shared_ip_groups.py<br />nova/api/openstack/shared_ip_groups/v10.py<br />* cp nova/api/openstack/shared_ip_groups/v10.py<br />nova/api/openstack/shared_ip_groups/v11.py<br /><br />Open nova/api/openstack/shared_ip_groups/v11.py and set ALL of the<br />Controller methods to raise faults.Fault(exc.HTTPNotImplemented()),<br />just as the Shared IP Groups controller currently does for update(),<br />delete(), and create():<br /><br /> def create(self, req):<br /> """ Creates a new Shared IP group """<br /> raise faults.Fault(exc.HTTPNotImplemented())<br /><br />-jay<br /><br />><br />><br />><br />> Waldon<br />><br />><br />><br />> -----Original Message-----<br />> From: "Jay Pipes" <jaypipes@gmail.com><br />> Sent: Friday, March 4, 2011 1:20pm<br />> To: "Brian Lamar" <brian.lamar@rackspace.com><br />> Cc: "openstack@lists.launchpad.net" <openstack@lists.launchpad.net><br />> Subject: Re: [Openstack] Multiple Versions in Openstack API<br />><br />> On Fri, Mar 4, 2011 at 12:28 PM, Brian Lamar <brian.lamar@rackspace.com><br />> wrote:<br />>> Unfortunately v1.0 -> v1.1 is not a minor version increase (despite the<br />>> names).<br />><br />> Ah, ok.<br />><br />>>> then if the v1.1 servers/ endpoint only *extends* the 1.0 version<br />>>> /servers endpoint and doesn't break it, then you could have:<br />>><br />>> This works for minor versions, but not major versions which have different<br />>> object formattings, a set of different top-level objects, and tons of other<br />>> inconsistencies.<br />>><br />>> IMO your method works fine for minor versions, but not between<br />>> major/breaking versions. We can still do v10 and v11 modules, but I would<br />>> steer away from thinking there is any sort of link between them except for<br />>> some supporting libraries.<br />><br />> Could you elaborate on an example of this inconsistency between 1.0<br />> and 1.1? That way, I'd have more to go on in thinking how to break<br />> the versioning into separate modules.<br />><br />> Thanks Brian!<br />> jay<br />><br />> _______________________________________________<br />> Mailing list: https://launchpad.net/~openstack<br />> Post to : openstack@lists.launchpad.net<br />> Unsubscribe : https://launchpad.net/~openstack<br />> More help : https://help.launchpad.net/ListHelp</p>
</div></font>