Hi everyone On Wed, Nov 23, 2011 at 10:43 PM, Chris Wright <chr...@sous-sol.org> wrote:
> * Brad Hall (b...@nicira.com) wrote: > > As for the directory structure, I agree that the current layout is > > cumbersome. The reason it was done was for ease of packaging; but if > > the distros are going to package it using spec/deb files anyways then > > it isn't necessary. What I was thinking is to move all of the pieces > > that were separated out from the quantum directory back into it and > > condense the paths. For example: > > > > <tree root>/client/lib/quantum/client/foo.py -> <tree > > root>/quantum/client/foo.py > > <tree root>/server/lib/quantum/api/foo.py -> <tree > > root>/quantum/server/api/foo.py > > Yeah, that makes sense to me. The only issue we had was with namespace > and use of extensions. So as long as that's kept w/in the quantum > namespace, should be good. That's much more clear. And it's going to be even better is we also deal with plugins path: <tree root>plugins/openvswitch-plugin/lib/quantum/plugins/openvswitch/ovs_quantum_plugin.py <tree root>plugins/openvswitch/ovs_quantum_plugin.py > > Which makes it similar to how it used to be. This requires that if we > > want to keep our current setup.py scheme we'll have to rename them to > > setup_server.py, setup_client.py, etc.. The setup_x.py can be a guide > > for how the distros are supposed to split Quantum into multiple > > packages. > > > > For the package split I think we still want to maintain > > client/server/common/plugins so the spec files would have to > > incorporate this. I don't think that should be too hard though as > > pretty much everything will be in the quantum-common package; the > > quantum-client package will include just the client binary, > > quantum-server will include server binary + etc directory, etc. > > Right, that's about how I see it too (note: for simplicity, the current > fedora package isn't this granular yet, but very much intended to be). For Debian packaging, there is no need to have different setup_X.py, although we are using all of them right now. Maybe for simplicity, we can manage to have just one, so there is no too much code to duplicate. > > Does that sound reasonable to you? > > It does, yes. > Absolutly. I only hope that the change happens not so close to the final essex release. Anyway, if you need a hand, I'm willing to help. Ghe Rivero -- .''`. Pienso, Luego Incordio : :' : `. `' `- www.debian.org www.hispalinux.es GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
