On 06/29/2012 12:54 PM, Dan Wendlandt wrote: > Hi Gary, > > Based on discussions during the last team meeting, I had created a BP to > discuss this in F-3 > (https://blueprints.launchpad.net/quantum/+spec/remove-v1-related-code), > though admittedly the work on the OVS + LB plugins in F-2 certainly also > raises the question.
I raised review issues this morning against both these plugins' V2 patches, arguing that they should simply implement the QuantumPluginBaseV2 interface and abandon the old V1 QuantumPluginBase interface. Trying to support both the V1 and V2 plugin interfaces adds complexity to both the plugins and their agents, since the DB schemata differ, and delays the V2 code getting adequate testing. I had mistakenly thought that the quantum API code was setup to support both the V1.x and V2.0 APIs using plugins that implement only the QuantumPluginBaseV2 interface. After looking more closely at the current API code, I now realize that quantum either functions in 1.x mode or in 2.0 mode (depending on which base class the configured plugin implements), and is not capable of supporting the 1.x and 2.0 APIs simultaneously. If we do maintain the V1.x API in Folsom, I think we should enhance the API code to support V1.x using V2 plugins, and remove the extra complexity of supporting both base interface from the plugins. If needed, we could also continue to support V1 plugins (for the V1.x API only) by having the API code check which base class the plugin implements. But I am not arguing that we necessarily do the above described work. I fully support doing as Dan describes in the remove-v1-release-code BP, removing all remnants of quantum ever having had a V1.x API. > > My bias is toward removing v1 support prior to the end of Folsom. My > motivation for this is to reduce the total amount of code under > management, as well as to avoid having to document and support two very > different models of using Quantum (since v1 did not include IPAM, it > required networks to be created using nova-manage with nova-network as a > proxy, and use nova-network for L3/NAT + DHCP). > > The reasons I think we can get away with dropping v1 support is that v2 > is a super-set of the functionality, and because (due to the use of nova > as a proxy), v1 never really was exposed directly to users. V1 was more > of an internal API between Nova and Quantum, and since we can update not > to use v2, I can't think of a case where dropping v1 support really > leaves someone in the lurch. This all makes sense to me. We can certainly update our oVirt+quantum PoC to use the V2 quantum API, although I don't think we'd be immediately making use of any of the L3 features. > > For the F-2 work on the OVS plugin, I encouraged Aaron to retain the v1 > code for the time being. The reason for this is that until we have > solid DHCP (targeted for F-2) and L3 + NAT (targeted for F-3) support in > Quantum itself, there are some use cases that cannot be done with v2 (in > particular, we could run and pass the standard gating tests, which test > things like floating IPs). > > I believe there are already plans to update both the NVP, UCS, and > (based on the other email thread Ryu as well) in F-3. > > Thoughts? I guess I'm OK with this for the openvswitch and linuxbridge plugins as a short term tactical approach. I really don't like the extra plugin and agent complexity, and would like to see all unit testing, devstack testing, and everything else using V2 APIs and V2 plugin implementations as soon as possible. If we go forward with this, and for some reason we don't get to the point where we can expunge the V1.x API by, lets say, F-3, then I strongly recommend we consider supporting the V1.x API in the API layer using V2 plugins, and at least get all plugins cleaned up and fully onto V2. As an alternative to the current approach of each plugin providing both its old QuantumPluginBase implementation and its new QuantumPluginBaseV2 implementation, it might be worth considering a different way of supporting V1. A class supporting QuantumPluginBaseV2 (via QuantumDbPluginV2) would be the only real plugin implementation, and only the new DB schema would be maintained (simplifying the agents). To support V1 mode, a simple adapter class supporting the old QuantumPluginBase interface would be configured as the core plugin, which would instantiate the real V2 plugin implementation class and delegate the V1 operations onto it. This could turn out to require less code than the current approach, would be less intrusive in the V2 plugin code, would simplify the agents, and, maybe most importantly, would get more mileage onto the real V2 plugin implementations sooner. Does this seem realistic? -Bob > > Dan > > > On Fri, Jun 29, 2012 at 4:55 PM, Gary Kotton <gkot...@redhat.com > <mailto:gkot...@redhat.com>> wrote: > > Hi, > With the advent of V2 do we want to continue to support V1? > - Yes: > - Do we want separate plugins or as Bob suggested have the V2 > plugin support V1 requests? V2 support for V1 may require changes in > the database. In addition to this we do not have a database upgrade. > - No: > - Should the current patches remove the V1 support. > - What about UCS and RYU? > My concerns are if someone adopts a Quantum implementation with V1 > support, how will they move to V2 without service disruption. > Thanks > Gary > > > -- > Mailing list: https://launchpad.net/~__netstack > <https://launchpad.net/~netstack> > Post to : netstack@lists.launchpad.net > <mailto:netstack@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~__netstack > <https://launchpad.net/~netstack> > More help : https://help.launchpad.net/__ListHelp > <https://help.launchpad.net/ListHelp> > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com <http://www.nicira.com> > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
