Open Stack

On Wed, Jan 15, 2014 at 1:29 PM, Dugger, Donald D <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.


>
>
> 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:joe.gordon0 at gmail.com]
> *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 <
> donald.d.dugger at intel.com> 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: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> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20140116/3b135b22/attachment.html>