Open Stack

2018-08-27 23:31 GMT+08:00 Matt Riedemann <mriedemos at gmail.com>:

> 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?).
>
> 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 can help some. And yes, small change is good than huge change.


>
> 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/e3173faf59bd1453
> c3800b2bf57c2af8cfde1697
> [5] https://github.com/EdLeafe/placement/commit/e984bef858700937
> 8ea430dd1c12ca3e40a3c901
>
> --
>
> Thanks,
>
> Matt
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20180828/49747dd3/attachment.html>