[ovs-dev] OVS / OVN split - post 2.12
nusiddiq at redhat.com
Tue Jul 23 12:33:50 UTC 2019
On Tue, Jul 23, 2019 at 5:53 PM Mark Michelson <mmichels at redhat.com> wrote:
> On 7/22/19 3:43 PM, Mark Michelson wrote:
> > Hi Numan,
> > On 7/22/19 2:35 PM, Numan Siddique wrote:
> >> Hi Ben, Mark and All,
> >> Now that branch 2.12 is created, shall we proceed with the OVS/OVN
> >> split ?
> >> In order to do the split we need to do the below tasks
> >> In ovn-org/ovn repo
> >> Step 1. Sync the ovs subtree to the latest (from the OVS repo).
> > This is a good point of discussion. What is the "latest"?
> > We could pull in the 2.12 branch as a subtree. Alternatively, we could
> > pull in the current master. My assumption is that we pull in master. As
> > long as we're using OVS as a subtree, we can just pull in the latest OVS
> > master as necessary, especially if we make changes to OVN that also
> > require changes in OVS. Also, pulling in master allows us to have a
> > subtree of OVS that has no OVN code in it.
I agree. We should pull in master.
> > Once we reach a point where OVS is not included as a subtree, then I
> > think this is less important. Then it will be more important to have
> > configure-time checks for features or OVS version. If the installation
> > of OVS isn't at some minimum version, then you need to update OVS.
> >> 2. Delete all the ovn related code from the root dir. Right now there
> >> is no history for the OVN files in the ovn-org/ovn repo
> > Aside from the history aspect, is there a reason to have an ovn
> > subdirectory? If there were a way to preserve history and allow the OVN
> > source to exist at the root, would that be desired? Or would people
> > prefer to have an ovn/ subdirectory anyway?
If you see the Poc repo here -
have OVN files in root folder just like how
you did it initially.
> >> 3. Copy OVN files from openvswitch/ovs repo using git-filter-branch.
> >> This will preserver the history.
> >> 4. Sync the test files from ovs subtree so that tests pass.
> > Does this just mean removing the non-OVN tests from the tests/
> > directory? Or does this imply that there are OVN tests that are not
> > passing in the ovn repo?
Once we sync to the latest ovs subtree, we will see test case failures as
tests/ovn.at here - https://github.com/ovn-org/ovn/blob/master/tests/ovn.at
After we sync ovs subtree to latest master we have 2 options
1. Just copy ovn.at from ovn-org/ovn/ovs/tests/ovn.at to ovn-org/ovn/tests/
Only small issue is we will be loosing the history for 2-3 months.
2. Copy ovn.at using git-filter-branch. This preseves history but we need
to delete non ovn related tests file again
since with git-filter-branch we can't prune just files.
Any thoughts here ? I would prefer (1) if everyone is fine if we loose
little bit of history.
> > I'm guessing based on the branch linked below you just mean removing
> > non-OVN tests. I just wanted to double-check.
> >> During this period its better to freeze merging OVN related patches in
> >> the OVS repo.
> >> And finally delete the OVN related code from the OVS repo.
> >> I have done a PoC here -
> >> https://github.com/numansiddique/ovn/commits/ovn_sync_from_ovs_v3/p4
> >> All the relates commits can be found here.
> >> Does these steps seem fine ? Any concerns ?
> >> If this seems fine, can we choose a date to start this process ?
> > I think when it comes to the purely technical aspects of the split, the
> > steps you've detailed should be good. There are updates to the
> > documentation and other aspects (ansible pocs, vagrant files, xenserver
> > directory) that should be done
> > Since you've got PoC commits for each of the four steps listed, it
> > should go smoothly. The only part that's scary is the removal of OVN
> > code from the OVS tree. I'm not sure any of us has attempted that yet.
> > In theory it should be simple. The parts
> I realized I cut myself short here. I was going to say that most of this
> task would involve removing files from the source. We'd also need to be
> sure to go through all documentation, build files, etc. to remove
> OVN-related items. And we also would need to be sure that we don't end
> up "losing" any OVN-related code/documentation. What I mean here is we
> need to ensure that if we delete something OVN-related from the OVS
> repo, then we need to be sure that is in the OVN repo.
I would say is to keep the OVN related code for a couple of weeks so that
openstack networking-ovn starts consuming OVN from the ovn repo. If we
don't give time,
their CI will break.
Once we do step (4), we can officially declare that OVN is split. But keep
the OVN related code
for a couple of weeks so that projects like openstack networking-ovn starts
consuming OVN from the
ovn repo. During this time, the OVS commitors should not apply any OVN
patches to the OVS repo.
> >> Thanks
> >> Numan
More information about the dev