On 3/21/24 17:09, Dumitru Ceara wrote: > All the TODO items listed in it have been addressed (for a while).
That's a bold statement. And I disagree. :) > OVN includes OVS as a submodule nowadays and there's a documented way > of bumping the OVS submodule version when needed. > > Signed-off-by: Dumitru Ceara <[email protected]> > --- > Makefile.am | 1 - > README.rst | 3 +- > TODO_SPLIT.rst | 116 ------------------------------------------------- > 3 files changed, 1 insertion(+), 119 deletions(-) > delete mode 100644 TODO_SPLIT.rst > > diff --git a/Makefile.am b/Makefile.am > index bfc9565e8b..9febd492aa 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -108,7 +108,6 @@ EXTRA_DIST = \ > Vagrantfile-FreeBSD \ > .mailmap \ > TODO.rst \ > - TODO_SPLIT.rst \ > ovn-architecture.7.xml \ > ovn-nb.ovsschema \ > ovn-nb.xml \ > diff --git a/README.rst b/README.rst > index 428cd8ee87..b5ce2a164b 100644 > --- a/README.rst > +++ b/README.rst > @@ -39,8 +39,7 @@ in userspace and therefore requires no kernel modules to be > installed. > > Until recently, OVN code lived within the Open vSwitch codebase. OVN has > recently been split into its own repo. There is much to do to complete this > -split entirely. See the TODO_SPLIT.rst file for a list of known tasks that > -need to be completed. > +split entirely. > > What's here? > ------------ > diff --git a/TODO_SPLIT.rst b/TODO_SPLIT.rst > deleted file mode 100644 > index 5f11205bab..0000000000 > --- a/TODO_SPLIT.rst > +++ /dev/null > @@ -1,116 +0,0 @@ > -.. > - Licensed under the Apache License, Version 2.0 (the "License"); you may > - not use this file except in compliance with the License. You may obtain > - a copy of the License at > - > - http://www.apache.org/licenses/LICENSE-2.0 > - > - Unless required by applicable law or agreed to in writing, software > - distributed under the License is distributed on an "AS IS" BASIS, > WITHOUT > - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See > the > - License for the specific language governing permissions and limitations > - under the License. > - > - Convention for heading levels in OVN documentation: > - > - ======= Heading 0 (reserved for the title in a document) > - ------- Heading 1 > - ~~~~~~~ Heading 2 > - +++++++ Heading 3 > - ''''''' Heading 4 > - > - Avoid deeper levels because they do not render well. > - > -======================== > -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. > - > -* Someone with a decent ability to write should give the README.rst file some > - 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. I don't think this particular item is done. For example the RHEL installation docs were not changed since the split and still describe how to build OVS rather than OVN. > - > -* 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. > - > -* The ovs-sandbox is in a similar state to the tests directory. That is, the > - tutorial/ directory contains a copy of the ovs-sandbox script. Rather than > - copying the script wholesale, it probably makes more sense to refer to the > - ovs version of the script from the ovn repo. Running the sandbox should > - also be altered so that the base ovs-sandbox script doesn't do anything > - ovn-related. Rather, the ovn repo can start the sandbox by calling into > - ovs and then start the ovn parts after. Two items above are not done either, but I'm not sure if they need to be done. > - > -* 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
