[openstack-dev] [Gantt] Looking for some answers...

Dugger, Donald D donald.d.dugger at intel.com
Mon Jan 6 21:09:16 UTC 2014


The specific steps I used clone the nova tree and then use this script to delete areas of the tree:

git filter-branch -f --index-filter "git rm -r -f --cached --ignore-unmatch $*" --prune-empty HEAD
if [ -d .git/refs/original ]
then
                                 git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
fi
git reflog expire --expire=now --all
git reset --hard
git gc --aggressive --prune=now

I was more concerned about retaining history for the files we kept than deleting unneeded history so there might be some extra history in the log.

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

From: Joshua Harlow [mailto:harlowja at yahoo-inc.com]
Sent: Monday, January 6, 2014 1:49 PM
To: OpenStack Development Mailing List (not for usage questions); Boris Pavlovic
Subject: Re: [openstack-dev] [Gantt] Looking for some answers...

Was the history filtered out using something like http://git-scm.com/docs/git-filter-branch??

There seems to be a lot of commit history that isn't related to gantt files (baremetal...)

Was the plan to figure out which files to keep, then cleanup that commit history?

I wouldn't expect https://github.com/openstack/gantt/commit/ff3c9afa35e646b72e94ba0c020ee37544e0e9dc (and others) to showup if those histories were removed...

From: Boris Pavlovic <bpavlovic at mirantis.com<mailto:bpavlovic at mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, January 6, 2014 at 12:08 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Gantt] Looking for some answers...

Russell,

It should be pretty easy to do this in gantt though.  Right now I would
probably do it against the current scheduler and then we'll port it
over.  I don't think we should do major work only in gantt until we're
ready to deprecate the current scheduler.


That make sense.

In couple of they we will try to make some "real" benchmarks using Rally, to ensure that no-db-scheduler works better then previous. So I hope we will get interest from community.


It's a new repo created with the history filtered out.  The history
was only maintained for code kept.  That seems pretty ideal to me.

Not sure that nova history is right history for scheduler (Why not Cinder for example? why exactly Nova?).
Imho Scheduler aaS for all projects and Nova Scheduler are different things.



Best regards,
Boris Pavlovic


On Mon, Jan 6, 2014 at 11:59 PM, Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:
On 01/06/2014 02:52 PM, Boris Pavlovic wrote:
> Vish,
>
> and as I understand it the hope will be to do the no-db-scheduler blueprint.
> There was quite a bit of debate on whether to do the no-db-scheduler stuff
> before or after the forklift and I think the consensus was to do the
> forklift
> first.
>
> Current Nova scheduler is so deeply bind to nova data models, that it is
> useless for every other project.
>
> So I don't think that forkit in such state of Nova Scheduler is useful
> for any other project.
It should be pretty easy to do this in gantt though.  Right now I would
probably do it against the current scheduler and then we'll port it
over.  I don't think we should do major work only in gantt until we're
ready to deprecate the current scheduler.

--
Russell Bryant

_______________________________________________
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/20140106/9697d1fd/attachment.html>


More information about the OpenStack-dev mailing list