On 25.04.2019 13:21, Ian Stokes wrote: > Hi All, > > At last weeks OVS community call [1] the topic of the UNH DPDK lab testing > OVS was raised, specifically the issue of the target branches being used so I > wanted to kick off a wider discussion on the ML. > > Currently the UNH Lab tests target the DPDK master branch and the dpdk-latest > branch in the OVS repo. > > To date, we've maintained the dpdk-latest branch by merging OVS master every > few weeks and applying any required patches to ensure compilation & existing > feature functionality with DPDK master branch at that time. > > A concern from UNH is that this introduces 2 moving targets i.e. breakages > could be introduced either by commits on DPDK master or a commit merged from > OVS master into dpdk-latest. > > From a UNH perspective, it was suggested that it would be easier if the > dpdk-latest branch did not have regularĀ merges from OVS master. Only patches > that enable DPDK master compilation and functionality would be committed to > dpdk-latest. > > This does reduce the scope of introducing breakage as now breakage should > only occur due to a change in DPDK master. > > However the advantage of keeping dpdk-latest in sync with both DPDK master > and OVS master is that there is better visibility WRT to changes required in > OVS master when it eventually transitions to the latest DPDK LTS release. > IMO, this process has worked well for the OVS community since being > introduced. > > I would prefer to keep the current process for dpdk-latest, my thinking here > is that before pushing the latest merge of OVS master to dpdk-latest it > should undergo validation testing anyhow (travis, unit tests, basic p2pĀ & > pvp). If these are passing before the changes are pushed then I would think > it there would be minimal danger at least WRT OVS code base changes breaking > the UNH tests. > > Another proposal suggested was that another branch could be introduced in the > OVS repo specifically to enable UNH OVS DPDK testing. I'm not a fan of this > however, I think it's adding overhead to avoid an issue (OVS master merge > causing dpdk-latest breakage) that should be addressed regardless if it > occurs. > > What are peoples thoughts?
Hi. I'd also prefer "current" model but with a few changes. I'm suggesting a periodic 'git pull --rebase' from master to dpdk-latest instead of merge. 'dpdk-latest' branch is not a stable branch and I don't think that anyone should use it on a regular basis. So it should be expected that this branch could be rebased at any time. This should not produce any issues for CI systems as they are commonly clones entire repo or checkouts branch to the new local branch. This way DPDK lab will test dpdk commits over the current 'dpdk-latest' branch of OVS which will be periodically moved to match with latest OVS master. Of course, the branch should be validated by Travis or local build before the force-push to avoid DPDK Lab test failures caused by OVS. We need to update the travis scripts on this branch to build with DPDK master. Rebasing produces exactly same number of conflicts as merging, however it keeps the history clean and readable. Current merge strategy only complicates the history making it impossible to say what commits are differ. And also in addition to resolving merge conflicts we'll have to resolve same conflicts again while pulling changes back to master while moving to next DPDK LTS. --- I have one important question: What we're trying to test? 1. Does it check that OVS builds with new DPDK? 2. Or it tests the OVS performance with new DPDK? 3. Or it tests DPDK patches that they doesn't break the API currently used by OVS? 4. Or it tests the performance of new OVS patches? The target of 1 could be achieved by the Travis build in OVS repo. The target of 2 does not have much in common with OVS. Achieved by simple DPDK performance tests already existed on lab.dpdk.org. The target of 3 makes no much sense because we need to fix OVS, not the DPDK. Covered by the target of question 1. The target of 4 is probably the most interesting, however it's not the case of building with latest DPDK master. This should be done by testing current OVS master with stable DPDK. So, what is the goal of this testing? I'm asking because there is no any information available here of on lab.dpdk.org. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev