On Mon, Aug 27, 2018 at 5:31 PM, Matt Riedemann <mriede...@gmail.com>
wrote:
On 8/24/2018 7:36 AM, Chris Dent wrote:
Over the past few days a few of us have been experimenting with
extracting placement to its own repo, as has been discussed at
length on this list, and in some etherpads:
https://etherpad.openstack.org/p/placement-extract-stein
https://etherpad.openstack.org/p/placement-extraction-file-notes
As part of that, I've been doing some exploration to tease out the
issues we're going to hit as we do it. None of this is work that
will be merged, rather it is stuff to figure out what we need to
know to do the eventual merging correctly and efficiently.
Please note that doing that is just the near edge of a large
collection of changes that will cascade in many ways to many
projects, tools, distros, etc. The people doing this are aware of
that, and the relative simplicity (and fairly immediate success) of
these experiments is not misleading people into thinking "hey, no
big deal". It's a big deal.
There's a strategy now (described at the end of the first etherpad
listed above) for trimming the nova history to create a thing which
is placement. From the first run of that Ed created a github repo
and I branched that to eventually create:
https://github.com/EdLeafe/placement/pull/2
In that, all the placement unit and functional tests are now
passing, and my placecat [1] integration suite also passes.
That work has highlighted some gaps in the process for trimming
history which will be refined to create another interim repo. We'll
repeat this until the process is smooth, eventually resulting in an
openstack/placement.
We talked about the github strategy a bit in the placement meeting
today [1]. Without being involved in this technical extraction work
for the past few weeks, I came in with a different perspective on the
end-game, and it was not aligned with what Chris/Ed thought as far as
how we get to the official openstack/placement repo.
At a high level, Ed's repo [2] is a fork of nova with large changes
on top using pull requests to do things like remove the non-placement
nova files, update import paths (because the import structure changes
from nova.api.openstack.placement to just placement), and then
changes from Chris [3] to get tests working. Then the idea was to
just use that to seed the openstack/placement repo and rather than
review the changes along the way*, people that care about what
changed (like myself) would see the tests passing and be happy enough.
However, I disagree with this approach since it bypasses our
community code review system of using Gerrit and relying on a core
team to approve changes at the sake of expediency.
What I would like to see are the changes that go into making the seed
repo and what gets it to passing tests done in gerrit like we do for
everything else. There are a couple of options on how this is done
though:
1. Seed the openstack/placement repo with the filter_git_history.sh
script output as Ed has done here [4]. This would include moving the
placement files to the root of the tree and dropping nova-specific
files. Then make incremental changes in gerrit like with [5] and the
individual changes which make up Chris's big pull request [3]. I am
primarily interested in making sure there are not content changes
happening, only mechanical tree-restructuring type changes, stuff
like that. I'm asking for more changes in gerrit so they can be
sanely reviewed (per normal).
2. Eric took a slightly different tack in that he's OK with just a
couple of large changes (or even large patch sets within a single
change) in gerrit rather than ~30 individual changes. So that would
be more like at most 3 changes in gerrit for [4][5][3].
3. The 3rd option is we just don't use gerrit at all and seed the
official repo with the results of Chris and Ed's work in Ed's repo in
github. Clearly this would be the fastest way to get us to a new repo
(at the expense of bucking community code review and development
process - is an exception worth it?).
I assumed that the work on github was done to _discover_ what steps
needs to be done later to populate the new repo and make the tests
pass. So I more like the #1 approach.
Option 1 would clearly be a drain on at least 2 nova cores to go
through the changes. I think Eric is on board for reviewing options 1
or 2 in either case, but he prefers option 2. Since I'm throwing a
wrench in the works, I also need to stand up and review the changes
if we go with option 1 or 2. Jay said he'd review them but consider
these reviews lower priority. I expect we could get some help from
some other nova cores though, maybe not on all changes, but at least
some (thinking gibi, alex_xu, sfinucan).
I will spend time reviewing the patches coming for the new placement
repo.
Cheers,
gibi
Any CI jobs would be non-voting while going through options 1 or 2
until we get to a point that tests should finally be passing and we
can make them voting (it should be possible to control this within
the repo itself using zuul v3).
I would like to know from others (nova core or otherwise) what they
would prefer, and if you are a nova core that wants option 1 (or 2)
are you willing to help review those incremental changes knowing it
will be a drain - but also realizing that we can't really let option
1 drag on while we're doing stein feature development, so ideally
this would be done before the PTG.
* Yes I realize I could be reviewing the github pull requests along
the way, but that's not really how we do code review in openstack.
[1]
http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-08-27-14.00.log.html#l-74
[2] https://github.com/EdLeafe/placement
[3] https://github.com/EdLeafe/placement/pull/3
[4]
https://github.com/EdLeafe/placement/commit/e3173faf59bd1453c3800b2bf57c2af8cfde1697
[5]
https://github.com/EdLeafe/placement/commit/e984bef8587009378ea430dd1c12ca3e40a3c901
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
