Hi Bob, Adding netstack list, as this conversation has grown in scope.
On Wed, Feb 15, 2012 at 6:56 AM, Robert Kukura <rkuk...@redhat.com> wrote: > On 02/14/2012 10:59 PM, Sumit Naiksatam (snaiksat) wrote: >> Hi Robert, >> >> (also adding Salvatore) >> >> Sorry, I could not revisit this thread earlier. I have similar concerns >> as Brad mentioned, but I do not have any better/brighter ideas as well. >> >> I do remember having seen the discussion around packaging the plugins in >> separate repos on our Netstack list before, and I can think we decided >> against it, don't quite recollect the exact reason. Having said that, if >> this is the best way to do it, then I guess we should move forward. >> >> Will doing this have an impact on Quantum stability? The last time >> around a number of issues cropped up after the packaging changes and >> they took a while to settle down (just thinking aloud about the E4 >> timelines). >> >> Thanks, >> ~Sumit. > > Hi Sumit, > > There are two different dimensions of granularity being discussed: > > One dimension is the packaging of each plugin separately from the > quantum core and from each other plugin. I don't see anything that > currently prevents distributions from doing this on their own, but I > tend to agree that organizing the plugins in separate repositories with > their own setup.py files, tests, tarballs, etc. would be worthwhile. I > think this is best discussed/decided in the context of the OpenStack > core application process, and I'm not taking a position yet on the > timing of this. I'm assuming one tarball is produced per repository, so > as long as the quantum repository contains plugins, distributions can > split these out into separate packages if they desire. Do we all agree > this dimension is a separate discussion that probably won't get resolved > (and implemented) today as part of this bug fix? Yes. Distributions can (and in my opinion should) split out what is currently in the main quantum server repo into multiple packages. > > The other dimension, and the one I'm trying to get resolved now for E4, > is whether to support the ability for distributions to package the code > that runs on the quantum server node(s) and the code that runs on nova > compute nodes such that neither pulls in the other (and more > importantly, neither pulls in the other's dependencies). To avoid > reorganizing the current python namespaces used by plugins, I'm simply > suggesting we make the python-quantumclient repository "own" the > quantum.plugins namespace, in the same way that it currently "owns" the > quantum namespace, allowing compute-node-only packages to install into > plugin-specific namespaces such as quantum.plugins.*.agent without > needing the server-node-only package installed. I think we agree on the goal, but I'm a somewhat confused about the proposed solution with respect to python-quantumclient. Right now, the nova-compute process does not depend on python-quantumclient, so I'm not sure how having python-quantumclient own the namespace helps things out with respect to other code that may need to be installed on the nova-compute host. I think the code you're talking about takes on of the following two forms, right? 1) vif-drivers that nova-compute may need to directly import (e.g., cisco plugin + bridge plugin have vif drivers). The plugin install instructions likely tell the user to copy them into the nova directory before using, but fundamentally there is no reason they can't be in a quantum.* namespace or even some other python namespace. 2) plugin-specific agents that run on the compute host and manipulate the software vswitch/bridge. (e.g., ovs plugin + bridge plugin has agents that run on compute host). These are completely independent of nova, and just run on the same host, so they too can be in any namespace. I'd like to understand the problem here better. Is the problem that multiple packages (e.g., both a quantum.plugins.openvswitch and a quantum.plugins.openvswitch.agent package) have overlapping python namespaces and someone would have to "own" it, while the other package would have to depend on the "owner"? If so, I would probably advocate that code intended to run on the compute node have a separate namespace such that no conflict of ownership exists. For example, quantum.agent.openvswitch... > > A related issue that I'd also like to resolve now for E4 is what python > namespace the plugin-specific nova drivers should be installed into. > Right now the plugin READMEs recommend copying driver files into > locations under the nova namespace. Distributions could do this, but > that would make the quantum (plugin) packages depend on the nova > packages that own those namespaces. Therefore, I'm suggesting we don't > copy them, but instead configure nova to reference them in the > quantum.plugins.*.nova namespaces that correspond to their current > source file locations. I'd simply update the READMEs and add appropriate > quantum/plugins/*/nova/__init__.py files to enable this as part of my > current bug fix. Yes, I like referencing them in a quantum-based namespace, rather than having them copied in. Hopefully I'm making sense here... I don't have a lot of experience with packaging. Thanks, Dan > > Thanks, > > -Bob > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: 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
