On Tue, May 19, 2026 at 8:40 PM Mark Michelson <[email protected]> wrote:
> Hi Ales, > > I like the way this is handled, since it mostly avoids the trap of > having to update the document frequently. However, there is one > exception down below. > Hi Mark, thank you for the review. > > On Wed, May 13, 2026 at 6:36 AM Ales Musil via dev > <[email protected]> wrote: > > > > Update example checkout versions from 20.09 to 26.03 (the > > latest LTS) in the general install guide. > > > > Remove the MSVC 2013 compiler reference since Windows was > > never officially supported. Update Docker base image > > references from Ubuntu 16.04 and CentOS 7 to Ubuntu 24.04 > > and Fedora to match the current container Dockerfiles. > > > > Update fedora.rst to reference RHEL 8.x+ and CentOS Stream > > instead of the EOL Fedora 29/30 and CentOS 7.x. > > > > In the upgrade guide, mention the current LTS versions > > (24.03 and 26.03) alongside the first LTS (22.03). > > Reorder the schema change notes to list the Release 22.12 > > note first and separate the pre-split Release 2.11 notes > > with a clear notice that they only apply when upgrading > > from OVN versions that were part of the OVS tree. > > > > Assisted-by: Claude Opus 4.6, OpenCode > > Signed-off-by: Ales Musil <[email protected]> > > --- > > Documentation/intro/install/fedora.rst | 13 ++-- > > Documentation/intro/install/general.rst | 17 ++--- > > Documentation/intro/install/ovn-upgrades.rst | 73 ++++++++++++-------- > > 3 files changed, 55 insertions(+), 48 deletions(-) > > > > diff --git a/Documentation/intro/install/fedora.rst > b/Documentation/intro/install/fedora.rst > > index a0c372251..1924fa0a9 100644 > > --- a/Documentation/intro/install/fedora.rst > > +++ b/Documentation/intro/install/fedora.rst > > @@ -21,18 +21,17 @@ > > > > Avoid deeper levels because they do not render well. > > > > -=========================================== > > -Fedora, RHEL 7.x+ Packaging for OVN > > -=========================================== > > +====================================== > > +Fedora, RHEL 8.x+ Packaging for OVN > > +====================================== > > > > This document provides instructions for building and installing OVN > > RPM packages on a Fedora Linux host. Instructions for the installation > of OVN > > -Fedora Linux host without using RPM packages can be found in the > > +on a Fedora Linux host without using RPM packages can be found in the > > :doc:`general`. > > > > -These instructions have been tested with Fedora 29 and 30, and are also > > -applicable for RHEL 7.x and its derivatives, including CentOS 7.x and > > -Scientific Linux 7.x. > > +These instructions are applicable for Fedora, RHEL 8.x and later, and > > +CentOS Stream. > > > > Build Requirements > > ------------------ > > diff --git a/Documentation/intro/install/general.rst > b/Documentation/intro/install/general.rst > > index 6745803a1..e622e044c 100644 > > --- a/Documentation/intro/install/general.rst > > +++ b/Documentation/intro/install/general.rst > > @@ -43,14 +43,14 @@ If, on the other hand, if you want to build a > particular released > > version, you can check it out by running a command such as the > > following from the "ovn" directory:: > > > > - $ git checkout v20.09.0 > > + $ git checkout v26.03.0 > > > > The repository also has a branch for each release series. For > > -example, to obtain the latest fixes in the OVN 20.09.x release series, > > +example, to obtain the latest fixes in the OVN 26.03.x release series, > > which might include bug fixes that have not yet been in any released > > version, you can check it out from the "ovn" directory with:: > > > > - $ git checkout origin/branch-20.09 > > + $ git checkout origin/branch-26.03 > > > > If you do not want to use Git, you can also obtain tarballs for `OVN > > release versions <https://www.ovn.org/en/releases/>`, or download a > > @@ -88,9 +88,6 @@ need the following software: > > > > - Clang 3.4 or later. > > > > - - MSVC 2013. Refer to :doc:`windows` for additional Windows build > > - instructions. > > - > > - libssl, from OpenSSL, is optional but recommended if you plan to > connect the > > OVN services to the OVN DB ovsdb-servers securely. If libssl is > installed, > > then OVN will automatically build with support for it. > > @@ -511,14 +508,12 @@ Start OVN containers using unix socket:: > > <docker_repo>:<tag> ovn-northd > > > > .. note:: > > - Current ovn central components comes up in docker image in a > standalone > > + Current OVN central components come up in Docker image in a > standalone > > and cluster mode with protocol tcp. > > > > - The debian docker file use ubuntu 16.04 as a base image for > reference. > > - > > - User can use any other base image for debian, e.g. u14.04, etc. > > + The Debian Dockerfile uses Ubuntu 24.04 as a base image for > reference. > > > > - RHEL based docker support is now added with centos7 as a base image. > > + RHEL-based Docker support uses Fedora as a base image. > > > > Starting OVN host service > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > diff --git a/Documentation/intro/install/ovn-upgrades.rst > b/Documentation/intro/install/ovn-upgrades.rst > > index c27b7f50e..f80fa09d0 100644 > > --- a/Documentation/intro/install/ovn-upgrades.rst > > +++ b/Documentation/intro/install/ovn-upgrades.rst > > @@ -79,8 +79,9 @@ The following rolling upgrade paths are supported: > > 1. LTS to the very next LTS release, or to any non-LTS in between the > two. > > 2. Any non-LTS to the very next LTS release. > > > > -The first LTS version of OVN was 22.03. If you want to upgrade between > other > > -versions, you can use the `Fail-safe upgrade`_ procedure. > > +The first LTS version of OVN was 22.03. The current LTS versions are > > +24.03 and 26.03. If you want to upgrade between other versions, you can > > +use the `Fail-safe upgrade`_ procedure. > > I think stating the current LTS versions here is not a good idea. It > means that every time the current LTS version changes, we have to > update this document or it will get out of date again. I think a good > way to handle this is something like: > > "The first LTS version of OVN was 22.03. Subsequent LTS versions have > been released every two years since then. For more information on the > lifetime of LTS versions, please see > https://www.ovn.org/en/releases/#long-term-support ." > > We update ovn.org with every OVN release, so pointing to ovn.org is > the most reliable way to ensure the document is up-to-date. > Yeah that makes sense. Updated in v2. > > > > > Fail-safe upgrade > > ~~~~~~~~~~~~~~~~~ > > @@ -181,13 +182,30 @@ If there were already data that violates the new > constraints got added somehow, > > it will result in DB upgrade failures. In this case, user should > manually > > correct data using ovn-nbctl (for north-bound DB) or ovn-sbctl (for > south- > > bound DB), and then upgrade again following previous steps. Below is a > list > > -of known impactible schema changes and how to fix when error > encountered. > > +of known incompatible schema changes and how to fix when error > > +encountered. > > > > -#. Release 2.11: index [type, ip] added for Encap table of south-bound > DB to > > - prevent duplicated IPs being used for same tunnel type. If there are > > - duplicated data added already (e.g. due to improper chassis > management), > > - a convenient way to fix is to find the chassis that is using the IP > > - with command:: > > +Post-split releases (20.03+) > > +'''''''''''''''''''''''''''' > > + > > +#. Release 22.12: index [transit_switch, availability_zone, route_table, > > + ip_prefix, nexthop] added for OVN Interconnection Southbound DB table > > + Route. If there are duplicated records in this table, users are > > + advised to upgrade ovn-ic daemons in all availability zones first and > > + after that convert the schema (restart ovn-ic database daemon). > > + > > +Pre-split releases (OVN 2.x) > > +''''''''''''''''''''''''''''' > > + > > +The following notes apply only when upgrading from versions where OVN > > +was part of the Open vSwitch tree. They can be ignored when upgrading > > +between standalone OVN releases (20.03+). > > + > > +#. Release 2.11: index [type, ip] added for Encap table of south-bound > > + DB to prevent duplicated IPs being used for same tunnel type. If > > + there are duplicated data added already (e.g. due to improper chassis > > + management), a convenient way to fix is to find the chassis that is > > + using the IP with command:: > > > > $ ovn-sbctl show > > > > @@ -195,35 +213,30 @@ of known impactible schema changes and how to fix > when error encountered. > > > > $ ovn-sbctl chassis-del <chassis> > > > > -#. Release 22.12: index [transit_switch, availability_zone, route_table, > > - ip_prefix, nexthop] added for OVN Interconnection Southbound DB > table Route. > > - If there are duplicated records in this table, users are advised to > upgrade > > - ovn-ic daemons in all availability zones first and after that > convert the > > - schema (restart ovn-ic database daemon). > > - > > #. Release 2.11 and earlier: The availability_zone name is added to the > > - external_ids in NB_Global. Therefore, when upgrading to latest > versions, > > - update the name column in NB_Global for each availability zone before > > - starting the ovn-ic daemons. The Northbound database upgrade does not > > - handle populating the name column part of schema upgrade. Failing to > do > > - this could result in data plane impact, such as remote AZs being > unable > > - to update port bindings during gateway chassis failover, new gateway > > - chassis CRUD, etc. Run below command to set the name column in > NB_Global > > - if upgrading from very old 2.* versions to latest/newer versions: > > + external_ids in NB_Global. Therefore, when upgrading to latest > > + versions, update the name column in NB_Global for each availability > > + zone before starting the ovn-ic daemons. The Northbound database > > + upgrade does not handle populating the name column part of schema > > + upgrade. Failing to do this could result in data plane impact, such > > + as remote AZs being unable to update port bindings during gateway > > + chassis failover, new gateway chassis CRUD, etc. Run below command > > + to set the name column in NB_Global if upgrading from very old 2.* > > + versions to latest/newer versions: > > > > $ ovn-nbctl set NB_Global . name=<availability zone name> > > > > Then restart ovn-ic daemons in all availability zones. > > > > - Missing above step will result in cpu of ovn-ic active instance spike > > + Missing above step will result in CPU of ovn-ic active instance spike > > to 100%. This occurs due to null name column as ovn-ic in each > > - availability zones repeatedly fails in commiting transaction to South > > - bound in remote availability zones due to duplicate chassis. This > will > > - also result in manual clean up remote availability zones gateway > chassis > > - of type interconnection in local availability zone causing data plane > > - impact. Fix these issues by below command on each availability zone > part > > - of upgrade from very old 2.* versions after stopping ovn-ic on all > > - availability zones: > > + availability zone repeatedly fails in committing transaction to > > + Southbound in remote availability zones due to duplicate chassis. > > + This will also result in manual clean up of remote availability zones > > + gateway chassis of type interconnection in local availability zone > > + causing data plane impact. Fix these issues by below command on each > > + availability zone part of upgrade from very old 2.* versions after > > + stopping ovn-ic on all availability zones: > > > > $ ovn-nbctl set NB_Global . name=<availability zone name> > > $ ovn-sbctl chassis-del <remote-ic-gateway-chassis-uuid> > > -- > > 2.54.0 > > > > _______________________________________________ > > dev mailing list > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > > Regards, Ales _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
