On 3/21/24 18:30, Ilya Maximets wrote:
> 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. :)
> 

It's the only type of statements I make. :)

>> 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.
> 

Hmm, good point, I'll update those in v2.

>> -
>> -* 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.
> 

I don't think they need anything done either.  Maybe just rename
ovs-sandbox to ovn-sandbox.

>> -
>> -* 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

Reply via email to