[openstack-dev] [gantt] Sync up patches

Dugger, Donald D donald.d.dugger at intel.com
Thu Jan 16 21:42:21 UTC 2014


OK, it looks like the concensus is that we don't try and keep the gantt tree in sync with nova instead we:

1)  Get the current gantt tree to pass unit tests
2)  Get gantt to pass integration tests (e.g. get it working as the nova scheduler)
3)  Modify devstack to optionally use gantt
4)  Freeze scheduler changes to nova as we:
      a)  Extract all the changes that were needed to get gantt working
      b)  Recreate the gantt tree from the current nova tree
      c)  Apply all the patches from step 4.a
5)  Unfreeze scheduler work but now all work is targeted exclusively to the gantt tree

Note that the current gantt tree has already changed the `nova' directory to `gantt' but there are more details for steps 1 and 2 that would be good to explicitly list.

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

-----Original Message-----
From: Russell Bryant [mailto:rbryant at redhat.com] 
Sent: Thursday, January 16, 2014 9:42 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [gantt] Sync up patches

On 01/16/2014 11:18 AM, Vishvananda Ishaya wrote:
> 
> On Jan 16, 2014, at 6:46 AM, Joe Gordon <joe.gordon0 at gmail.com 
> <mailto:joe.gordon0 at gmail.com>> wrote:
> 
>> 
>> 
>> 
>> On Wed, Jan 15, 2014 at 1:29 PM, Dugger, Donald D 
>> <donald.d.dugger at intel.com <mailto:donald.d.dugger at intel.com>>
>> 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.

That sounds OK to me, but I would really just like to see gantt running before we freeze nova-scheduler.

Joe's idea might work for this too, which would be something like:

1) Go through the exercise of making the current thing running using the current repo (without keeping it in sync).  This includes devstack integration.

2) Once we see it working and are ready for the nuclear freeze and switch, re-generate the repo from nova master and apply everything needed to make it work.

--
Russell Bryant

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



More information about the OpenStack-dev mailing list