On Jan 16, 2014, at 6:46 AM, Joe Gordon <[email protected]> wrote:
> > > > On Wed, Jan 15, 2014 at 1:29 PM, Dugger, Donald D <[email protected]> > wrote: > My thought was to try and get some parallel effort going, do the resync as a > continuing task as suffer a little ongoing pain versus a large amount of pain > at the end. Given that the steps for a resync are the same no matter when we > do it waiting until the end is acceptable. > > > > From a `just do it’ perspective I think we’re in violent agreement on the top > level tasks, as long as your step 3, integration testing, is the same as what > I’ve been calling working functionality, e.g. have the nova scheduler use the > gantt source tree. > > > > PS: How I resync. What I’ve done is create a list with md5sums of all the > files in nova that we’ve duplicated in gantt. I then update a nova git tree > and compare the current md5sums for those files with my list. I use > format-patch to get the patches from the nova tree and grep for any patch > that applies to a gantt file. I then use `git am’ to apply those patches to > the gantt tree, modifying any of the patches that are needed. > > > So this sync won't work once we start the nova/gantt rename, so we need a > better approach. > > Syncing the gantt tree with nova sounds like a daunting task. Perhaps it > would be easier if we use the current gantt tree as a test to see what is > involved in getting gantt working, and then redo the fork after the icehouse > feature freeze with the aim of getting the gantt tree working by the start of > juno, so we can have the freeze nova-scheduler discussion. Syncing nova and > gantt during feature freeze should be significantly easier then doing it now. I would personally just vote for the nuclear approach of freezing nova scheduler and doing work in gantt. If close to icehouse 3 we see that gantt is not going to be ready in time we can selectively backport stuff to nova-scheduler and push gantt to juno. Vish > > > > > It may sound a little cumbersome but I’ve got some automated scripts that > make it relatively easy and modifying the patches, the hard part, was going > to be necessary no matter how we do it. > > > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > > > From: Joe Gordon [mailto:[email protected]] > Sent: Wednesday, January 15, 2014 10:21 AM > > > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [gantt] Sync up patches > > > > > > > > On Wed, Jan 15, 2014 at 8:52 AM, Dugger, Donald D <[email protected]> > wrote: > > The current thought is that I will do the work to backport any change that > are made to the nova tree that overlap the gantt tree. I don’t see this as > an impossible task. Yes it will get harder as we make specific changes to > gantt but, given that our first goal is to make gantt a drop in replacement > for the nova scheduler there shouldn’t be that many gantt specific changes > that would make backporting difficult so I think this is a doable path. > > > > How are you tracking this today? I think its worth having a well documented > plan for this, as we will most likely have to keep syncing the two repos for > a while. > > > > If all that is needed to cherry-pick a patch from nova to gantt is a > nova=>gantt rename these should be easy and a single +2 makes sense, but for > any patch that requires changes beyond that I think a full review should be > required. > > > > > > For the ordering, the unit tests and working functionality are indeed > effectively the same, highest priority, I don’t have an issue with getting > the unit tests working first. > > > > Great, so I would prefer to see gantt gating on unit tests before landing any > other patches. > > > > Whats the full plan for the steps to bootstrap? It would be nice to have a > roadmap for this so we don't get bogged down in the weeds. Off the top of my > head I imagine it would be something like (I have a feeling I am missing a > few steps here): > > > > 1) Get unit tests working > > 2) Trim repo > > 3) Set up integration testing (In parallel get gantt client working) > > 4) Resync with nova > > > > > > As far as trimming is concerned I would still prefer to do that later, after > we have working functionality. Since trimable files won’t have gantt > specific changes keeping them in sync with the nova tree is easy. Until we > have working functionality we won’t really know that a file is not needed (I > am constantly surprised by code that doesn’t do what I expect) and deleting a > file after we are sure it’s not needed is easy. > > > > Fair enough, I moved trimming after get unit tests working in the list above. > > > > > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > > > From: Joe Gordon [mailto:[email protected]] > Sent: Wednesday, January 15, 2014 9:28 AM > > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [gantt] Sync up patches > > > > > > > > On Tue, Jan 14, 2014 at 2:22 PM, Dugger, Donald D <[email protected]> > wrote: > > All- > > > > I want to clear up some confusion I’m seeing in the reviews of these syncup > patches. These patches merely bring recent changes from the nova tree over > to the gantt tree. There is no attempt to actually change the code for > gantt, that is a separate task. Our first goal is to have the scheduler in > gantt do exactly what the scheduler in nova does. We want to be able to > reliably change nova to use the gantt source tree as a drop in replacement, > get that working before we start making gantt specific changes. > > > > As far as I can tell this is the first time we have tried to fork a > repository without a freeze on the original codebase (when we split out > cinder, nova-volume was frozen). With this form of forking, syncing the > repos becomes harder, and I am concerned with the sync method proposed here. > Once we do the big rename (%s/nova/gantt/g) in the gantt repo, we can't just > cherry-pick patches across without any modifications (assuming we gate on the > unit tests). So going forward how are we planning on keeping the two repos in > sync? > > > > Is there an outline of the bootstrap process for Gantt? I would imagine the > first goal (before landing any sync patches) would be to get the unit tests > working. > > > > > > > > The gantt tree probably has extra code that can be trimmed out later but, as > long as that code exists in gantt I want to make it a synced up copy of the > code in nova. > > > > I'm not sure if I agree with the ordering proposed here. I would rather see > gantt be trimmed first. > > > > > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > > > From: Dugger, Donald D > Sent: Tuesday, January 14, 2014 2:48 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [gantt] Sync up patches > > > > All- > > > > As threatened, I’ve pushed 24 patches to sync up the gantt tree to recent > changes to the nova tree. They’re all linked in a dependency chain starting > at: > > > > https://review.openstack.org/66717 > > > > It’s be good if we can get those reviewed soon. > > > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
