So, while looking at this, I discovered the file you guys have, version.py. I've been working on a standalone library, vcsversion (https://github.com/emonty/vcsversion) which does some similar things and which encapsulates some of the logic that's current in the build_tarball.sh script. I'd love to (doesn't need to happen to today) port any missing functionality that's in version.py into vcsversion and get quantum et al using it.
Great minds think alike, right? :) Monty On 01/10/2012 02:48 PM, Dan Wendlandt wrote: > Ok, based on the meeting today we are going ahead with this. > > Blueprint created and assigned to > monty: https://blueprints.launchpad.net/quantum/+spec/separate-client-repo > > Monty, I assume that you will setup the infrastructure, then at some > point need to hand off to a quantum dev (or not). Please ping the list > when you get to that point. > > And as cdub mentioned at the end of the meeting, the sooner we can do > this, the better in terms of distros that will need to change their > packaging in time for essex. > > thanks for driving this. > > Dan > > > On Tue, Jan 3, 2012 at 1:00 PM, Monty Taylor <mord...@inaugust.com > <mailto:mord...@inaugust.com>> wrote: > > ++ > > I think as a parallel thing, some of the things that are in > quantum.common _might_ want to live in openstack.common. > > On 01/03/2012 12:55 PM, Brad Hall wrote: > > I still vote for #2. I don't think there will be a ton of > duplication so we're probably ok in that regard. Also, it sounds > like following suit will make life easier for the ci folks. I think > #3 will be painful (both in initial work and maintenance). > > > > If we do #2 then we could put quantum-client in tools/pip-requires > and there wouldn't be much of any additional burden on the developer > unless they were also going to work on the client -- in which case > pull a separate repo. > > > > Thanks, > > Brad > > > > On Jan 3, 2012, at 12:47 AM, Dan Wendlandt wrote: > > > >> Hi folks, > >> > >> tl;dr we need to decide on splitting client repo out of main > repo, per monty's comments. Because this is what all other > openstack projects are doing, bias is to move in that direction, but > benefits are not clear. If we do split, my suggestion is to create > two repos (client/server), not three repos (client/server/common) > >> > >> longer version: > >> > >> At the 11/29 netstack meeting, one of the topics discussed was > how to handle monty's suggestion that we split out the client into > another repo. > >> > >> From the 11/29 meeting, here's some background: > >> > >> 22:12:59 <mtaylor> danwent: > >> the problem is that we've got projects that need to depend on > this stuff (horizon being a good example) > >> > >> 22:13:17 <mtaylor> > >> so we need to be able to reference the actual thing that's > needed, wihtout pulling in the entire server > >> > >> 22:13:31 <danwent> mtaylor: > >> definitely understand that.. we want to be able to package > things separately, definitely > >> > >> 22:13:40 <cdub> > >> sounds more like packagin then repo mgmt > >> > >> 22:13:51 <danwent> > >> I think the question is why packaging needs to be tied to repo > so tightly. > >> > >> 22:13:58 <cdub> > >> e.g. simple to build multpile packages from a single repo > >> > >> 22:13:59 <danwent> > >> i definitely understand that you have a lot of experience here… :) > >> > >> 22:14:17 <danwent> cdub: > >> yes, in fact that is what we do already. > >> > >> 22:14:23 <cdub> > >> right > >> > >> 22:14:25 <mtaylor> > >> it's for a few reasons > >> > >> 22:14:42 <mtaylor> > >> pip requires git lines can't reference sub directories > >> > >> 22:15:01 <mtaylor> > >> so you wind up with venv installs that require actual releases > to pypi to be consumable > >> > >> 22:15:36 <mtaylor> > >> additionally, once you start having submodules in tree, standard > tooling winds up being difficult to apply - knowing to interact with > a setup.py in trunk is straight forward > >> > >> 22:15:50 <mtaylor> > >> knowing that there are 4 setup.py files spread throughout the > tree is less obviouos > >> > >> 22:16:05 <bhall> > >> as of yesterday all setup.py's are in the root :) > >> > >> 22:16:24 <danwent> > >> ok, so the trade-off here is if we want the pip files of other > projects to automatically pull "trunk", we need separate repos? > >> > >> 22:16:41 <mtaylor> > >> yes > >> > >> 22:17:21 <mtaylor> > >> also, it's the model we're using for the other projects, so in > keeping with a consistent project-wide approach, I'd kind of want to > hear a really good reason that it can't work > >> > >> 22:17:28 <bhall> > >> how many repos are we talking about? client, common, server, > plugins? > >> > >> 22:18:16 <danwent> > >> I'm also worried about trying to keep quantum simple enough that > its easy for new people to join and hack on the project > >> > >> 22:18:25 <mtaylor> > >> I don't think, as of yet, that we need separate ones for plugins > >> > >> 22:18:55 <mtaylor> > >> the most important one in my brain in client - as we have a > python-*client project either in existence or coming in to existence > for every openstack project > >> > >> 22:19:08 <bhall> > >> could we go with two repos? client, common/server/plugins > >> > >> 22:19:11 <mtaylor> > >> the common one is just because that's how you've organized your > code - and i believe client depends on it, yeah/ > >> > >> 22:19:18 <mtaylor> > >> does client depend on common? > >> > >> 22:19:25 <danwent> > >> I believe that was the original goal > >> > >> 22:19:50 <danwent> > >> but perhaps we should revisit that… I'm not sure how much is > currently shared. > >> > >> 22:19:58 <bhall> > >> I think it does currently > >> > >> 22:20:06 <bhall> > >> yeah, I don't think there is a lot of code that it depends on > >> > >> 22:20:17 <danwent> mtaylor: > >> so the main goal here is pip install, which are mainly targetted > at developers right? > >> > >> 22:21:05 <danwent> > >> (I assume non-developers will get everything via packages, which > should have dependencies described in terms of packages) > >> > >> 22:21:43 <mtaylor> danwent: > >> yes > >> > >> 22:22:12 <danwent> > >> ok, thanks for the explanations… I think I understand this > better now, but still need to noodle on whether there are ways we > can both be happy :) > >> > >> 22:22:18 <mtaylor> danwent: > >> there is no thought that people will be doing production > releases from pip :) > >> > >> 22:22:23 <mtaylor> danwent: awesome > >> > >> An here's some more follow-up from the 12/6 meeting: > >> > >> 22:18:55 <danwent> > >> first, as discussed last week with mtaylor, we need to figure > out our strategy for whether we are going to split quantum into > multiple repos. > >> > >> 22:19:49 <salv> > >> before deciding on a strategy let's decide whether we want to > split the repos or not! :) > >> > >> 22:20:02 <mtaylor> danwent: > >> re that: we've got openstack.common going now - so perhaps > quantum.common can live there? > >> > >> 22:20:03 <danwent> > >> we can have the detailed discussion on the ML, but the > high-level options seem to be (1) keep as is, all one repo (2) split > into two repos, client and server, but potentially duplicate the > little bits of shared code and (3) split into three repos, client, > server, and common > >> > >> 22:20:09 <salv> > >> Splitting in which way exactly? client and server components? > >> > >> 22:20:30 <danwent> mtaylor: > >> I was thinking something very similar myself, if we decide to go > with #2 > >> > >> 22:20:57 <danwent> salv: > >> up for discussion > >> > >> 22:21:14 <danwent> #TODO: #danwent, start ML thread for splitting > repos, include #mtaylor as well > >> 22:21:17 <bhall> > >> my vote is for #2 (client and "the rest") > >> > >> 22:21:19 <mtaylor> #2 with some elements in openstack.common > would be the thing that matches the other projects more closely > >> 22:21:55 <danwent> if anyone else wants to comment now, go ahead, > otherwise i'll forward this content to start a thead on the ML > >> > >> It seems like we have three primary options (feel free to suggest > others). > >> > >> #1: do nothing, keep every in single repo > >> #2: split into two repos: client + server, but potentially > duplicate some of the shared code currently in "common" > >> #3: split into three repos, client, server and common. > >> > >> A couple thoughts: > >> > >> I'm still not totally clear on the value of splitting the repos. > Multiple repos are not required for anyone installing openstack via > packages, as we can easily generate separate client/server packages > when using a single repo (in fact, we already do). My understanding > is that splitting the repos aims to help developers in the case > where a project like horizon specifies a dependency on quantum by > adding a direct reference to the quantum git repo in pip-requires. > So one thing I'd like to better understand is the cost of > specifying a quantum git repo that includes client + server, as > opposed to one that just includes the client. If its just a matter > of pulling down some more bytes, that doesn't seem that painful (the > quantum source is tiny anyway). Is there some greater benefit to > splitting repos that I am missing? > >> > >> I think the cost of splitting repos is non-trivial, as it makes > it harder for developers to get things running from source tree, > (again, I'm assuming this is mainly a developer issue, as users > should mainly install from packages). It may also mean we need to > duplicate some common code, though the need for that may go down if > we can get both client + server code bases to have common code in > openstack-common. > >> > >> Another important consideration is that it seems that all of the > other openstack projects are moving to a model with the client in a > separate repo from the service itself. There would definitely a > cost both in terms of developer confusion and pain to the > infrastructure team to Quantum being an oddball in that department. > This alone may be reason enough to follow suit, but I'd love if > there was a clear cut reason other than "everyone else is doing it". > >> > >> If we do decide to split repos, my bias would be for #2, which > avoid the even more significant complexity of having three repos. > While some code in common may need to be duplicated, it may be the > case that such code is duplicated because it really belongs in > something like openstack-common, which could be a dependency of > both. A lof of the code in quantum.common seems to be of that > variety (I suspect much of this code is actually only used by the > server at this point). The two chunks of common code used by the > main client library are: > >> > >> from quantum.common import exceptions > >> from quantum.common.serializer import Serializer > >> > >> Serializer seems to be pretty much all stock code that should be > in openstack-common. > >> > >> The quantum client only uses a few of the Exceptions classes in > common/exeptions.py. A few of these may need to be duplicated in > both the client/server code. Though if we make the changes > suggested by Aaron to use only standard HTTP error codes, the > applicability of this code to the client decreases to the point of > almost no overlap, I suspect. > >> > >> Please chime in with your thoughts. Right now I'm not sure who > would work on this, so if you think you have some cycles, please > speak up. > >> > >> Dan > >> > >> > >> -- > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> Dan Wendlandt > >> Nicira Networks: www.nicira.com <http://www.nicira.com> > >> twitter: danwendlandt > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > >> -- > >> Mailing list: https://launchpad.net/~netstack > >> Post to : netstack@lists.launchpad.net > <mailto:netstack@lists.launchpad.net> > >> Unsubscribe : https://launchpad.net/~netstack > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks: 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
