Open Stack

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.

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.

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.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

From: Joe Gordon [mailto:joe.gordon0 at gmail.com]
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 <donald.d.dugger at intel.com<mailto:donald.d.dugger at intel.com>> 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<tel:303%2F443-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<tel:303%2F443-3786>


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140115/78b85ca4/attachment.html>