Thanks for the update, Ales! Acked-by: Mark Michelson <[email protected]>
On Mon, May 25, 2026 at 2:50 AM Ales Musil <[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]> > --- > v2: Rebase on top of latest main. > Adjust the reference to latest LTS. > --- > Documentation/intro/install/fedora.rst | 13 ++-- > Documentation/intro/install/general.rst | 17 ++--- > Documentation/intro/install/ovn-upgrades.rst | 76 ++++++++++++-------- > 3 files changed, 58 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..53c62c04a 100644 > --- a/Documentation/intro/install/ovn-upgrades.rst > +++ b/Documentation/intro/install/ovn-upgrades.rst > @@ -79,8 +79,12 @@ 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. 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 . If you want to > +upgrade between other versions, you can use the `Fail-safe upgrade`_ > +procedure. > > Fail-safe upgrade > ~~~~~~~~~~~~~~~~~ > @@ -181,13 +185,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 +216,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
