Bug 1964668

commit 32a197f845106da48833dd6194abcce01114cbe4
Author: Ilya Maximets <i.maximets>
Date:   Wed Apr 21 15:48:16 2021 +0200

    dpif-netdev: Remove meter rate from the bucket size calculation.
    
    Implementation of meters supposed to be a classic token bucket with 2
    typical parameters: rate and burst size.
    
    Burst size in this schema is the maximum number of bytes/packets that
    could pass without being rate limited.
    
    Recent changes to userspace datapath made meter implementation to be
    in line with the kernel one, and this uncovered several issues.
    
    The main problem is that maximum bucket size for unknown reason
    accounts not only burst size, but also the numerical value of rate.
    This creates a lot of confusion around behavior of meters.
    
    For example, if rate is configured as 1000 pps and burst size set to 1,
    this should mean that meter will tolerate bursts of 1 packet at most,
    i.e. not a single packet above the rate should pass the meter.
    However, current implementation calculates maximum bucket size as
    (rate + burst size), so the effective bucket size will be 1001.  This
    means that first 1000 packets will not be rate limited and average
    rate might be twice as high as the configured rate.  This also makes
    it practically impossible to configure meter that will have burst size
    lower than the rate, which might be a desirable configuration if the
    rate is high.
    
    Inability to configure low values of a burst size and overall inability
    for a user to predict what will be a maximum and average rate from the
    configured parameters of a meter without looking at the OVS and kernel
    code might be also classified as a security issue, because drop meters
    are frequently used as a way of protection from DoS attacks.
    
    This change removes rate from the calculation of a bucket size, making
    it in line with the classic token bucket algorithm and essentially
    making the rate and burst tolerance being predictable from a users'
    perspective.
    
    Same change will be proposed for the kernel implementation.
    Unit tests changed back to their correct version and enhanced.
    
    Signed-off-by: Ilya Maximets <i.maximets>
    Acked-by: Eelco Chaudron <echaudro>
    Reviewed-by: Tonghao Zhang <xiangxia.m.yue>

commit 1b4d8fe1d9cd1b558f2f093f909090c49fcda6b4
Author: Dumitru Ceara <dceara>
Date:   Mon May 17 11:22:27 2021 +0200

    ovsdb-idl: Consider all tables when computing expected cond seqno.
    
    In ovsdb_idl_db_set_condition(), take into account all pending
    condition changes for all tables when computing the db->cond_seqno at
    which the monitor is expected to be updated.
    
    In the following scenario, with two tables, A and B, the old code
    performed the following steps:
    1. Initial db->cond_seqno = X.
    2. Client changes condition for table A:
       - A->new_cond gets set
       - expected cond seqno returned to the client: X + 1
    3. ovsdb-idl sends the monitor_cond_change for table A
       - A->req_cond <- A->new_cond
    4. Client changes condition for table B:
       - B->new_cond gets set
       - expected cond seqno returned to the client: X + 1
       - however, because the condition change at step 3 is still not replied
         to, table B's monitor_cond_change request is not sent yet.
    5. ovsdb-idl receives the reply for the condition change at step 3:
       - db->cond_seqno <- X + 1
    6. ovsdb-idl sends the monitor_cond_change for table B
    7. ovsdb-idl receives the reply for the condition change at step 6:
      - db->cond_seqno <- X + 2
    
    The client was incorrectly informed that it will have all relevant
    updates for table B at seqno X + 1 while actually that happens later, at
    seqno X + 2.
    
    Fixes: 46437c5232bd ("ovsdb-idl: Enhance conditional monitoring API")
    Acked-by: Ben Pfaff <blp>
    Signed-off-by: Dumitru Ceara <dceara>
    (cherry picked from commit b5bb044fbe4c1395dcde5cc7d5081ef0099bb8b3)
    Signed-off-by: Ilya Maximets <i.maximets>

commit 9acbf2cff7df1389e069eeb74a78c7f625a2459f
Author: Wang Yibo <bobxxwang>
Date:   Thu May 6 11:14:07 2021 +0800

    ovs-ofctl: Fix coredump when using "add-groups" command.
    
    When using ovs-ofctl add-groups with only "switch" argument, a coredump
    is generated.  The main reason is that the command "ovs-ofctl add-groups"
    need two arguments but the limitation of min-args of this command is
    set to 1.
    
    Fixes: 7395c05254df ("Implement OpenFlow 1.1+ "groups" protocol.")
    Submitted-at: https://github.com/openvswitch/ovs/pull/360
    Signed-off-by: Wang Yibo <bobxxwang>
    Signed-off-by: Ilya Maximets <i.maximets>

commit 058702e3dcc61700bd587621d750d80985660a54
Author: Ilya Maximets <i.maximets>
Date:   Thu May 6 14:47:31 2021 +0200

    raft: Transfer leadership before creating snapshots.
    
    With a big database writing snapshot could take a lot of time, for
    example, on one of the systems compaction of 300MB database takes
    about 10 seconds to complete.  For the clustered database, 40% of this
    time takes conversion of the database to the file transaction json
    format, the rest of time is formatting a string and writing to disk.
    Of course, this highly depends on the disc and CPU speeds.  300MB is
    the very possible database size for the OVN Southbound DB, and it might
    be even bigger than that.
    
    During compaction the database is not available and the ovsdb-server
    doesn't do any other tasks.  If leader spends 10-15 seconds writing a
    snapshot, the cluster is not functional for that time period.  Leader
    also, likely, has some monitors to serve, so the one poll interval may
    be 15-20 seconds long in the end.  Systems with so big databases
    typically has very high election timers configured (16 seconds), so
    followers will start election only after this significant amount of
    time.  Once leader is back to the operational state, it will
    re-connect and try to join the cluster back.  In some cases, this might
    also trigger the 'connected' state flapping on the old leader
    triggering a re-connection of clients.  This issue has been observed
    with large-scale OVN deployments.
    
    One of the methods to improve the situation is to transfer leadership
    before compacting.  This allows to keep the cluster functional,
    while one of the servers writes a snapshot.
    
    Additionally logging the time spent for compaction if it was longer
    than 1 second.  This adds a bit of visibility to 'unreasonably long
    poll interval's.
    
    Reported-at: https://bugzilla.redhat.com/1960391
    Signed-off-by: Ilya Maximets <i.maximets>
    Acked-by: Dumitru Ceara <dceara>

commit 3bc41e2b6a170dcd6b5c728a4ed3410a6ce0865d
Author: Hariprasad Govindharajan <hariprasad.govindharajan>
Date:   Fri Apr 23 13:16:37 2021 +0100

    dpdk: Use DPDK 19.11.8 release.
    
    Modify ci linux build script to use the latest DPDK stable release.
    Modify Documentation to use the latest DPDK stable release 19.11.8
    Update NEWS file to reflect the latest DPDK stable release.
    
    Building DPDK releases 19.11.6 and 19.11.7,with meson was
    found to break the OvS build.
    DPDK 19.11.8 was released to fix the above said issue.
    Link to the discussion about the issue can be found below:
    http://mails.dpdk.org/archives/stable/2021-April/029786.html
    
    Signed-off-by: Hariprasad Govindharajan <hariprasad.govindharajan>
    Acked-by: Sunil Pai G <sunil.pai.g>
    Signed-off-by: Ian Stokes <ian.stokes>

commit fbebe7377dc00bd0627588f48d37b9b2658b6532
Author: Ilya Maximets <i.maximets>
Date:   Tue May 11 15:20:49 2021 +0200

    github: Fix up malformed /etc/hosts.
    
    For some reason /etc/hosts in GHA now contains a plain text line
    like this:
    
      Note: Don't Delete this file. Also, don't remove this line. ...
    
    This breaks libunbound and makes a series of unit tests to emit
    following warning:
      |00001|dns_resolve|WARN|Failed to read etc/hosts: syntax error
    
    Working around this issue by removing a bad line from /etc/hosts
    until this fixed properly by GitHub team.  This in combination
    with other fixes should unblock CI.
    
    Bug for virtual-environments:
      https://github.com/actions/virtual-environments/issues/3353
    
    Signed-off-by: Ilya Maximets <i.maximets>
    Reviewed-by: David Marchand <david.marchand>
    Acked-by: Aaron Conole <aconole>

commit 2a3d1f497152505e2d27febf1ff5329e3a277164
Author: Ilya Maximets <i.maximets>
Date:   Mon May 10 17:57:45 2021 +0200

    doc: automake: Add support for sphinx 4.0.
    
    File layout for man pages in sphinx 4 by default changed [1] from:
    
      Documentation/_ref/man/page.section
    
     to:
    
      Documentation/_ref/man/section/page.section
    
    Ajusting our build scripts so they will be able to locate files
    in new places.  This fixes our CI build.
    
    [1] https://github.com/sphinx-doc/sphinx/issues/7996
    
    Signed-off-by: Ilya Maximets <i.maximets>
    Acked-by: Ben Pfaff <blp>
    Reviewed-by: David Marchand <david.marchand>
    Reviewed-by: Aaron Conole <aconole>

commit 4ab5524dbb6f71232230a4a7cd7e13313c5db28b
Author: Ilya Maximets <i.maximets>
Date:   Thu May 6 14:27:23 2021 +0200

    cirrus: Look up existing versions of python dependencies.
    
    FreeBSD sometimes changes the base version of python3 that is
    used for packages.  This affects package names.  For example,
    currently CI is broken, because there is no more py37- versions
    of sphinx and openssl available, only py38- ones:
    
      pkg: No packages available to install matching 'py37-openssl'
           have been found in the repositories
      pkg: No packages available to install matching 'py37-sphinx'
           have been found in the repositories
    
    We had the same issue last year with 3.6 -> 3.7 transition:
      dfa2e3d04948 ("cirrus: Use python 3.7 packages on FreeBSD.")
    
    Fixing that by searching for a package instead of using a specific
    version.  This should help to avoid same issues in the future.
    
    Signed-off-by: Ilya Maximets <i.maximets>
    Reviewed-by: Aaron Conole <aconole>
    Acked-by: Kevin Traynor <ktraynor>
    Reviewed-by: David Marchand <david.marchand>

commit ea98fe0743d6902ab4b521e54cfa8edc467e703d
Author: Ben Pfaff <blp>
Date:   Thu May 6 10:41:40 2021 -0700

    ofp-group: Use big-enough buffer in ofputil_format_group().
    
    GCC 11 pointed out that ofputil_group_to_string()'s prototype asks for
    a buffer with one byte more than supplied.  This fixes the problem.
    
    This wasn't a buffer overflow because ofputil_group_to_string() honors
    the buffer size passed in, which was correct.  The worst that could
    happen was truncating the last byte of a group name.
    
    Signed-off-by: Ben Pfaff <blp>
    Acked-by: Paolo Valerio <pvalerio>