On 02/15/2012 03:00 PM, Dan Wendlandt wrote: > Hi Bob, > > Adding netstack list, as this conversation has grown in scope. > > On Wed, Feb 15, 2012 at 6:56 AM, Robert Kukura <[email protected]> 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.
With RPM in Fedora, each target system file and directory is generally owned by exactly one RPM. See http://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership and http://fedoraproject.org/wiki/Packaging:ReviewGuidelines for details. So if /usr/lib/python*/site-packages/quantum is owned by the python-quantumclient RPM, then all other RPMs that install anything anywhere under this directory have a direct or indirect dependency on the python-quantumclient RPM. I'm not sure if similar requirements apply to other distributions. All I'm suggesting here is that this same python-quantumclient RPM also own the /usr/lib/python*/site-packages/quantum/plugins directory (and its __init__.py file), so that no additional RPM (say quantum-server) necessarily needs to be installed for a plugin's agent or nova drivers RPM to be installed. > > 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. Right. > > 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"? Yes, its the exactly one owner constraint discussed above. > 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... That's one possible approach. But what if the plugin's agent, drivers, and/or plugin itself needed to share plugin-specific code? I guess the quantum.common.openvswitch namespace would work for this. Given the work to do and tight schedule for completing Essex, I've been leaning towards approaches with little or no impact on the existing code. Longer term, more thought might lead to better solutions. To be honest, splitting packages on the compute node vs quantum server node dimension is not that critical for Fedora Essex packaging. I'm not sure anyone is even thinking about doing that for nova. I'm happy to drop it for now if we don't quickly get consensus on a simple way to enable it. But this is definitely an area that will get more difficult to change as plugins proliferate. > > >> >> 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. Seems we are reaching consensus on this. Unless someone objects, I'll go ahead and update the READMEs and do whatever else is needed so that the drivers and agents are run from the quantum.plugins.*.agent and quantum.plugins.*.nova namespaces as part of the fix for bug 925074. But I'm not planning to move the openvswitch drivers from nova to quantum as part of this. That could be done later if desired. > > Hopefully I'm making sense here... I don't have a lot of experience > with packaging. Thanks, I think so. I'm no expert on packaging either, especially python packaging. -Bob > > Dan > > >> >> Thanks, >> >> -Bob >> >> > > > -- Mailing list: https://launchpad.net/~netstack Post to : [email protected] Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
