As Ilya commented in the review of the V1 of this series [0] the statement that "all the TODO items listed in it have been addressed" is indeed "a bold statement". However quite a few don't seem applicable anymore.
[0] https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412704.html Signed-off-by: Dumitru Ceara <[email protected]> --- TODO_SPLIT.rst | 73 -------------------------------------------------- 1 file changed, 73 deletions(-) diff --git a/TODO_SPLIT.rst b/TODO_SPLIT.rst index 9c65f77d87..cdc2d25ba7 100644 --- a/TODO_SPLIT.rst +++ b/TODO_SPLIT.rst @@ -25,9 +25,6 @@ OVN/OVS Split To-do List ======================== -Immediate tasks ---------------------------- - * There are likely many unused files throughout the source tree since they pertain to OVS rather than OVN. These can also be removed from the repo. @@ -36,73 +33,3 @@ Immediate tasks polish (or even just rewrite it. I won't be offended). * Cleanup the acinclude.m4 and m4 folder - -Immediate to Short-term tasks ------------------------------ - -* The Documentation/ directory can use an overhaul. Non-OVN content can be - removed. The installation guide and tutorials should be reworked to be - geared towards OVN specifically instead of OVS. - -* The tests/ directory contains copies of all "utility" files from the ovs - repo. These files could be removed in favor of using the files directly - from the ovs repo instead of the copy. As an example, ofproto-macros.at could - be removed from the tests/ directory, and we could reference the version in - the ovs repo instead. There are many other files that this could be done with. - -* OVN code needs to be removed from the OVS repo. This should be mostly - straightforward with a couple of exceptions. There is an include/ovn/ - directory in the ovs repo that should be moved to the ovn repo instead of - being removed. The other challenge is updating the ovsdb clustering tests. - They currently make use of the OVN database schemas. They will need to be - updated not to rely on something from OVN. - -* The rhel/ and debian/ directories need updating and testing so that they can - build ovn. They also need to be modified so that they no longer can build ovs - packages. - -Short to Medium-term tasks --------------------------- - -* There are several non-code subdirectories in the ovn repo that have not - been updated from how they existed in the OVS repo. It should be evaluated - if there is potential use to modify these to be useful for OVN or if they - should just be removed. Examples include the poc/ and xenserver/ directories. - -Medium to Long-term tasks -------------------------- - -* The goal is to eventually not require having ovs as a subtree in the ovn - repo. Using variables in Makefiles goes a short way towards realizing - this goal, but it only partially gets us there. We still - refer to the ovs subtree directly in certain areas, most notably the - tests/ directory. Getting rid of the ovs subtree can be thought of as a - two-step process: - - 1) Remove all direct references to the ovs subtree from the build system. By - doing this, it will be possible to have an ovs source repo checked out at - some other location and have ovn refer to that by using variables. - - 2) Alter ovs's build so that it places headers, utilities, etc. in known - locations on disk when it installs. This way, rather than referring to - an ovs source repo, we can refer to installation directories in the ovn - build system. This way, it could be possible to build ovn just by installing - the development package of ovs as a prerequisite. - -* A plan needs to be developed for compatibility between OVN and OVS. There - are several facets to this - - 1) We need to try to determine a policy with regards to what OVS versions - OVN will be compatible with. - - 2) The ovs subtree in ovn currently is the master branch of ovs at the time - that the ovn repo was split off. It likely will result in a more stable - environment to use a released version of ovs as our basis instead of an - arbitrary commit from mid-release. - - 3) While ovn was housed in the ovs repo, it was sometimes necessary to - update ovs or ovsdb code in order to facilitate a new ovn feature. Or it - might be necessary to fix a bug in ovs in order to fix a bug in ovn. With ovn - split away, there needs to be a way that ovn developers can contribute changes - to ovs when necessary but also not have to wait for those changes to be - available in an ovs release to be able to use them in ovn. -- 2.44.0 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
