Recheck-request: github-robot-_ovn-kubernetes
Rosemarie O'Riorden Lowell, MA, United States [email protected] On Wed, Aug 12, 2026 at 6:36 PM Rosemarie O'Riorden via dev < [email protected]> wrote: > Reported-at: https://redhat.atlassian.net/browse/FDP-3051 > Signed-off-by: Rosemarie O'Riorden <[email protected]> > --- > v3: > - Added this commit to address this part of the ticket. > --- > Documentation/automake.mk | 1 - > Documentation/topics/index.rst | 1 - > Documentation/topics/ovn-news-2.8.rst | 278 -------------------------- > 3 files changed, 280 deletions(-) > delete mode 100644 Documentation/topics/ovn-news-2.8.rst > > diff --git a/Documentation/automake.mk b/Documentation/automake.mk > index 916113c4c..685ba9588 100644 > --- a/Documentation/automake.mk > +++ b/Documentation/automake.mk > @@ -34,7 +34,6 @@ DOC_SOURCE = \ > Documentation/topics/incremental-processing/index.rst \ > > Documentation/topics/incremental-processing/incremental-processing.rst \ > Documentation/topics/integration.rst \ > - Documentation/topics/ovn-news-2.8.rst \ > Documentation/topics/role-based-access-control.rst \ > Documentation/topics/vif-plug-providers/index.rst \ > Documentation/topics/vif-plug-providers/vif-plug-providers.rst \ > diff --git a/Documentation/topics/index.rst > b/Documentation/topics/index.rst > index e5ba92b7b..0b676a98b 100644 > --- a/Documentation/topics/index.rst > +++ b/Documentation/topics/index.rst > @@ -41,7 +41,6 @@ OVN > incremental-processing/index > high-availability > role-based-access-control > - ovn-news-2.8 > vif-plug-providers/index > testing > test-development > diff --git a/Documentation/topics/ovn-news-2.8.rst > b/Documentation/topics/ovn-news-2.8.rst > deleted file mode 100644 > index 0d2568a3a..000000000 > --- a/Documentation/topics/ovn-news-2.8.rst > +++ /dev/null > @@ -1,278 +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. > - > -=============================== > -What's New with OVS and OVN 2.8 > -=============================== > - > -This document is about what was added in Open vSwitch 2.8, which was > released > -at the end of August 2017, concentrating on the new features in OVN. It > also > -covers some of what is coming up in Open vSwitch and OVN 2.9, which is > due to > -be released in February 2018. OVN has many features, and this document > does > -not cover every new or enhanced feature (but contributions are welcome). > - > -This document assumes a basic familiarity with Open vSwitch, OVN, and > their > -associated tools. For more information, please refer to the Open vSwitch > and > -OVN documentation, such as the ``ovn-architecture``\(7) manpage. > - > -Debugging and Troubleshooting > ------------------------------ > - > -Before version 2.8, Open vSwitch command-line tools were far more painful > to > -use than they needed to be. This section covers the improvements made to > the > -CLI in the 2.8 release. > - > -User-Hostile UUIDs > -~~~~~~~~~~~~~~~~~~ > - > -The OVN CLI, through ``ovn-nbctl``, ``ovn-nbctl``, and ``ovn-trace``, used > -full-length UUIDs almost everywhere. It didn't even provide any > assistance > -with completion, etc., which in practice meant always cutting and pasting > UUIDs > -from one command or window to another. This problem wasn't limited to the > -places where one would expect to have to see or use a UUID, either. In > many > -places where one would expect to be able to use a network, router, or port > -name, a UUID was required instead. In many places where one would want > to see > -a name, the UUID was displayed instead. More than anything else, these > -shortcomings made the CLI user-hostile. > - > -There was an underlying problem that the southbound database didn't > actually > -contain all the information needed to provide a decent user interface. > In some > -cases, for example, the human-friendly names that one would want to use > for > -entities simply weren't part of the database. These names weren't > necessary > -for correctness, only for usability. > - > -OVN 2.8 eased many of these problems. Most parts of the CLI now allow > the user > -to abbreviate UUIDs, as long as the abbreviations are unique within the > -database. Some parts of the CLI where full-length UUIDs make output hard > to > -read now abbreviate them themselves. Perhaps more importantly, in many > places > -the OVN CLI now displays and accepts human-friendly names for networks, > -routers, ports, and other entities. In the places where the names were > not > -previously available, OVN (through ``ovn-northd``) now copies the names > into > -the southbound database. > - > -The CLIs for layers below OVN, at the OpenFlow and datapath layers with > -``ovs-ofctl`` and ``ovs-dpctl``, respectively, had some similar problems > in > -which numbers were used for entities that had human-friendly names. Open > -vSwitch 2.8 also solves some of those problems. Other than that, the most > -notable enhancement in this area was the ``--no-stats`` option to > ``ovs-ofctl > -dump-flows``, which made that command's output more readable for the cases > -where per-flow statistics were not interesting to the reader. > - > -Connections Between Levels > -~~~~~~~~~~~~~~~~~~~~~~~~~~ > - > -OVN and Open vSwitch work almost like a stack of compilers: the OVN > Neutron > -plugin translates Neutron configuration into OVN northbound configuration, > -which ``ovn-northd`` translates into logical flows, which > ``ovn-controller`` > -translates into OpenFlow flows, which ``ovs-vswitchd`` translates into > datapath > -flows. For debugging and troubleshooting it is often necessary to > understand > -exactly how these translations work. The relationship from a logical > flow to > -its OpenFlow flows, or in the other direction, from an OpenFlow flow back > to > -the logical flow that produced it, was often of particular interest, but > OVN > -didn't provide good tools for the job. > - > -OVN 2.8 added some new features that ease these jobs. ``ovn-sbctl > lflow-list`` > -has a new option ``--ovs`` that lists the OpenFlow flows on a particular > -chassis that were generated from the logical flows that it lists. > -``ovn-trace`` also added a similar ``--ovs`` option that applies to the > logical > -flows it traces. > - > -In the other direction, OVN 2.8 added a new utility ``ovn-detrace`` that, > given > -an Open vSwitch trace of OpenFlow flows, annotates it with the logical > flows > -that yielded those OpenFlow flows. > - > -Distributed Firewall > -~~~~~~~~~~~~~~~~~~~~ > - > -OVN supports a distributed firewall with stateful connection tracking to > ensure > -that only packets for established connections, or those that the > configuration > -explicitly allows, can ingress a given VM or container. Neutron uses this > -feature by default. Most packets in an OpenStack environment pass > through it > -twice, once after egress from the packet's source VM and once before > ingress > -into its destination VM. Before OVN 2.8, the ``ovn-trace`` program, which > -shows the path of a packet through an OVN logical network, did not > support the > -logical firewall, which in practice made it almost useless for Neutron. > - > -In OVN 2.8, ``ovn-trace`` adds support for the logical firewall. By > default it > -assumes that packets are part of an established connection, which is > usually > -what the user wants as part of the trace. It also accepts command-line > options > -to override that assumption, which allows the user to discover the > treatment of > -packets that the firewall should drop. > - > -At the next level deeper, prior to Open vSwitch 2.8, the OpenFlow tracing > -command ``ofproto/trace`` also supported neither the connection tracking > -feature underlying the OVN distributed firewall nor the "recirculation" > feature > -that accompanied it. This meant that, even if the user tried to look > deeper > -into the distributed firewall mechanism, he or she would encounter a > further > -roadblock. Open vSwitch 2.8 added support for both of these features as > well. > - > -Summary Display > -~~~~~~~~~~~~~~~ > - > -``ovn-nbctl show`` and ``ovn-sbctl show``, for showing an overview of the > OVN > -configuration, didn't show a lot of important information. OVN adds some > more > -useful information here. > - > -DNS, and IPAM > -------------- > - > -OVN 2.8 adds a built-in DNS server designed for assigning names to VMs and > -containers within an OVN logical network. DNS names are assigned using > records > -in the OVN northbound database and, like other OVN features, translated > into > -logical flows at the OVN southbound layer. DNS requests directed to the > OVN > -DNS server never leave the hypervisor from which the request is sent; > instead, > -OVN processes and replies to the request from its ``ovn-controller`` local > -agent. The OVN DNS server is not a general-purpose DNS server and cannot > be > -used for that purpose. > - > -OVN includes simple built-in support for IP address management (IPAM), in > which > -OVN assigns IP addresses to VMs or containers from a pool or pools of IP > -addresses delegated to it by the administrator. Before OVN 2.8, OVN IPAM > only > -supported IPv4 addresses; OVN 2.8 adds support for IPv6. OVN 2.8 also > enhances > -the address pool support to allow specific addresses to be excluded. > Neutron > -assigns IP addresses itself and does not use OVN IPAM. > - > -High Availability > ------------------ > - > -As a distributed system, in OVN a lot can go wrong. As OVN advances, it > adds > -redundancy in places where currently a single failure could disrupt the > -functioning of the system as a whole. OVN 2.8 adds two new kinds of high > -availability. > - > -ovn-northd HA > -~~~~~~~~~~~~~ > - > -The ``ovn-northd`` program sits between the OVN northbound and southbound > -databases and translates from a logical network configuration into logical > -flows. If ``ovn-northd`` itself or the host on which it runs fails, then > -updates to the OVN northbound configuration will not propagate to the > -hypervisors and the OVN configuration freezes in place until > ``ovn-northd`` > -restarts. > - > -OVN 2.8 adds support for active-backup HA to ``ovn-northd``. When more > than > -one ``ovn-northd`` instance runs, it uses an OVSDB locking feature to > -automatically choose a single active instance. When that instance dies or > -becomes nonresponsive, the OVSDB server automatically choose one of the > -remaining instance(s) to take over. > - > -L3 Gateway HA > -~~~~~~~~~~~~~ > - > -In OVN 2.8, multiple chassis may now be specified for L3 gateways. When > more > -than one chassis is specified, OVN manages high availability for that > gateway. > -Each hypervisor uses the BFD protocol to keep track of the gateway nodes > that > -are currently up. At any given time, a hypervisor uses the > highest-priority > -gateway node that is currently up. > - > -OVSDB > ------ > - > -The OVN architecture relies heavily on OVSDB, the Open vSwitch database, > for > -hosting the northbound and southbound databases. OVSDB was originally > selected > -for this purpose because it was already used in Open vSwitch for > configuring > -OVS itself and, thus, it was well integrated with OVS and well supported > in C > -and Python, the two languages that are used in Open vSwitch. > - > -OVSDB was well designed for its original purpose of configuring Open > vSwitch. > -It supports ACID transactions, has a small, efficient server, a flexible > schema > -system, and good support for troubleshooting and debugging. However, it > lacked > -several features that are important for OVN but not for Open vSwitch. As > OVN > -advances, these missing features have become more and more of a problem. > One > -option would be to switch to a different database that already has many of > -these features, but despite a careful search, no ideal existing database > was > -identified, so the project chose instead to improve OVSDB where necessary > to > -bring it up to speed. The following sections talk more about recent and > future > -improvements. > - > -High Availability > -~~~~~~~~~~~~~~~~~ > - > -When ``ovsdb-server`` was only used for OVS configuration, high > availability > -was not important. ``ovsdb-server`` was capable of restarting itself > -automatically if it crashed, and if the whole system went down then Open > -vSwitch itself was dead too, so the database server's failure was not > -important. > - > -In contrast, the northbound and southbound databases are centralized > components > -of a distributed system, so it is important that they not be a single > point of > -failure for the system as a whole. In released versions of OVN, > -``ovsdb-server`` supports only "active-backup replication" across a pair > of > -servers. This means that if one server goes down, the other can pick it > back > -up approximately where the other one left off. The servers do not have > -built-in support for deciding at any given time which is the active and > which > -the backup, so the administrator must configure an external agent to do > this > -management. > - > -Active-backup replication is not entirely satisfactory, for multiple > reasons. > -Replication is only approximate. Configuring the external agent requires > extra > -work. There is no benefit from the backup server except when the active > server > -fails. At most two servers can be used. > - > -A new form of high availability for OVSDB is under development for the > OVN 2.9 > -release, based on the Raft algorithm for distributed consensus. Whereas > -replication uses two servers, clustering using Raft requires three or more > -(typically an odd number) and continues functioning as long as more than > half > -of the servers are up. The clustering implementation is built into > -``ovsdb-server`` and does not require an external agent. Clustering > preserves > -the ACID properties of the database, so that a transaction that commits is > -guaranteed to persist. Finally, reads (which are the bulk of the OVN > workload) > -scale with the size of the cluster, so that adding more servers should > improve > -performance as the number of hypervisors in an OVN deployment increases. > As of > -this writing, OVSDB support for clustering is undergoing development and > early > -deployment testing. > - > -RBAC security > -~~~~~~~~~~~~~ > - > -Until Open vSwitch 2.8, ``ovsdb-server`` had little support for access > control > -within a database. If an OVSDB client could modify the database at all, > it > -could make arbitrary changes. This was sufficient for most uses case to > that > -point. > - > -Hypervisors in an OVN deployment need access to the OVN southbound > database. > -Most of their access is reads, to find out about the OVN configuration. > -Hypervisors do need some write access to the southbound database, > primarily to > -let the other hypervisors know what VMs and containers they are running > and how > -to reach them. Thus, OVN gives all of the hypervisors in the OVN > deployment > -write access to the OVN southbound database. This is fine when all is > well, > -but if any of the hypervisors were compromised then they could disrupt the > -entire OVN deployment by corrupting the database. > - > -The OVN developers considered a few ways to solve this problem. One way > would > -be to introduce a new central service (perhaps in ``ovn-northd``) that > provided > -only the kinds of writes that the hypervisors legitimately need, and then > grant > -hypervisors direct access to the southbound database only for reads. But > -ultimately the developers decided to introduce a new form of more access > -control for OVSDB, called the OVSDB RBAC (role-based access control) > feature. > -OVSDB RBAC allows for granular enough control over access that > hypervisors can > -be granted only the ability to add, modify, and delete the records that > relate > -to themselves, preventing them from corrupting the database as a whole. > - > -Further Directions > ------------------- > - > -For more information about new features in OVN and Open vSwitch, please > refer > -to the NEWS file distributed with the source tree. If you have questions > about > -Open vSwitch or OVN features, please feel free to write to the Open > vSwitch > -discussion mailing list at [email protected]. > -- > 2.55.0 > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
