[ovs-git] [ovn-org/ovn] e8e667: controller: Monitor all logical flows that refer t...

Dumitru Ceara noreply at github.com
Wed Apr 21 12:09:27 UTC 2021


  Branch: refs/heads/branch-21.03
  Home:   https://github.com/ovn-org/ovn
  Commit: e8e667dd92f3f27fc7b485752ae2ee45fef884af
      https://github.com/ovn-org/ovn/commit/e8e667dd92f3f27fc7b485752ae2ee45fef884af
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M controller/ovn-controller.c

  Log Message:
  -----------
  controller: Monitor all logical flows that refer to datapath groups.

Considering two logical datapaths (DP1 and DP2) and a logical flow that
is shared between the two, ovn-northd will create the following SB
records:

Datapaths: DP1, DP2
Logical_DP_Group: DPG1 {dps=[DP1, DP2]}
Logical_Flow: LF {dp_group=DPG1}

If an ovn-controller is conditionally monitoring DP1 and DP2 its
monitor conditions look like this:

Logical_DP_Group table when:
 - Logical_DP_Group.datapaths includes [DP1._uuid or DP2._uuid]
Logical_Flow table when:
 - Logical_Flow.logical_datapath in {DP1._uuid, DP2._uuid}
 - Logical_Flow.logical_dp_group in {DPG1._uuid}

If at this point a new logical datapath DP3 is created (e.g., a LS is
added) and the logical flow LF is shared with this third datapath, then
ovn-northd populates the SB with the following contents, replacing
old DPG1 with DPG1-new:

Datapaths: DP1, DP2, DP3
Logical_DP_Group: DPG1-new {dps=[DP1, DP2, DP3]}
Logical_Flow: LF {dp_group=DPG1-new}

At this point, the SB ovsdb-server will send the following updates to
ovn-controller, to match the current monitor condition it requested:

Datapaths:
- "insert" DP3

Logical_DP_Group:
- "delete" DPG1
- "insert" DPG1-new {dps=[DP1, DP2, DP3]}

Logical_Flow:
- "delete" LF

DPG1-new is inserted in the client's view of the database because its
datapaths include DP1 and DP2 which are part of the client's monitor
condition for Logical_DP_Group.  However, the logical flow is deleted
from the client's view of the database because the monitor condition
for Logical_Flow records doesn't include DPG1-new._uuid.

Now ovn-controller will:
- delete all openflows corresponding to LF, including the ones generated
  for datapaths DP1 and DP2.
- compute new set of monitor conditions and send the monitor_cond_change
  request to the SB:

Logical_DP_Group.datapaths includes
        [DP1._uuid or DP2._uuid or DP3._uuid]
Logical_Flow table when:
 - Logical_Flow.logical_datapath in {DP1._uuid, DP2._uuid, DP3._uuid}
 - Logical_Flow.logical_dp_group in {DPG1-new._uuid}

Upon processing this new set of conditions, the SB sends the following
update:
Logical_Flow:
- "insert" LF <--- now LF.logical_dp_group matches the condition.

Finally, ovn-controller will add all openflows that correspond to LF, on
all datapaths, DP1, DP2, DP3.

There is therefore a window in which traffic on DP1 and DP2 might be
dropped because openflows corresponding to LF1 on DP1 and DP2 have been
removed but not yet reinstalled.

To avoid this we now unconditionally monitor all logical flows that
refer to datapath groups.

Fixes: 4b946b366c4c ("controller: Add support for Logical Datapath Groups.")
Reported-at: https://bugzilla.redhat.com/1947056
Suggested-by: Ilya Maximets <i.maximets at ovn.org>
Acked-by: Ilya Maximets <i.maximets at ovn.org>
Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Acked-by: Mark Michelson <mmichels at redhat.com>
Signed-off-by: Numan Siddique <numans at ovn.org>
(cherry picked from commit d41a337fe3b608a8f90de8722d148344011f0bd8)


  Commit: 1110424ab571ff24449893896308821e44edd970
      https://github.com/ovn-org/ovn/commit/1110424ab571ff24449893896308821e44edd970
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M tests/system-ovn.at

  Log Message:
  -----------
  system-ovn.at: Make tests more portable.

Due to slight differences in behavior and/or output of some of the
utilities used by the tests when run on different distributions some
tests were failing, e.g., when run on Ubuntu 20.04.

Use "tcpdump -nn" to avoid host and port resolution;  also update "nc"
usage to avoid options that behave differently on various distributions.

This commit adds no guarantee that tests will pass on all possible
distributions, only tested on: Fedora 32 and Ubuntu 20.04.

Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Acked-by: Mark D. Gray <mark.d.gray at redhat.com>
(cherry picked from commit 9648000de30e5e8049827bc4bbf24f4f64093ebc)


  Commit: 195062f27320b8689b79dfd7fd3df459746ffc60
      https://github.com/ovn-org/ovn/commit/195062f27320b8689b79dfd7fd3df459746ffc60
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M .ci/linux-build.sh
    M .github/workflows/test.yml

  Log Message:
  -----------
  ci: Enable OVN system tests in GitHub Actions runs.

For now only enable system tests using the kernel datapath.  Running
the system tests with the userspace datapath makes some tests fail
due to known issues in the OVS userspace conntrack implementation which
are actively worked on.

To save CI time, only enable system test runs for a single item in the
test matrix ("linux gcc system-test").

We're also moving to Ubuntu 20.04 LTS in CI to avoid hitting:
https://bugzilla.redhat.com/1550097

Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Acked-by: Mark D. Gray <mark.d.gray at redhat.com>
(cherry picked from commit e45e94b005038201149588625d6b01fc1c6dbb29)


  Commit: f9e6cd57755bc41c4fb5dd593ef311625a7614e0
      https://github.com/ovn-org/ovn/commit/f9e6cd57755bc41c4fb5dd593ef311625a7614e0
  Author: Numan Siddique <numans at ovn.org>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M tests/ovn-macros.at
    M tests/ovn.at

  Log Message:
  -----------
  tests: Fix frequent failure of "4 HV, 1 LS, 1 LR, packet test with HA distributed router gateway port:".

This test is failing quite often due to timing issues.  The failures are
mainly due to the packet not received by the other side of the tunnel.
The test case resets the pcap file and then injects the packet.  And
this packet gets lost sometimes if the pcap files are not reset yet.
To fix this issue the test now ensures that ovs-vswitchd resets the
pcap file before injecting the packet.  The test also now adds
some waits to make sure flows related to tunnels are programmed
when the chassisresident port moves from one gw chassis to other.

Signed-off-by: Numan Siddique <numans at ovn.org>
Acked-by: Mark Michelson <mmichels at redhat.com>
(cherry picked from commit 879ebc8c64199209aa2fe11ca7fd2504384a605f)


  Commit: d265eda8412c14bf47bc64c239d5e3d4ac7437eb
      https://github.com/ovn-org/ovn/commit/d265eda8412c14bf47bc64c239d5e3d4ac7437eb
  Author: Dan Williams <dcbw at redhat.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M utilities/ovn-lib.in

  Log Message:
  -----------
  ovn-lib: harmonize stop_ovn_daemon() with ovs-lib

OVN should probably be doing the same things OVS is doing here.

Signed-off-by: Dan Williams <dcbw at redhat.com>
Signed-off-by: Numan Siddique <numans at ovn.org>
Acked-by: Mark Michelson <mmichels at redhat.com>
(cherry picked from commit d7db8702e778370a732d8ac0a7771a2905de65a7)


  Commit: a542f95797c498a1bc16559c0841bb99cf3c246a
      https://github.com/ovn-org/ovn/commit/a542f95797c498a1bc16559c0841bb99cf3c246a
  Author: Dan Williams <dcbw at redhat.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M utilities/ovn-ctl
    M utilities/ovn-lib.in

  Log Message:
  -----------
  ovn-ctl: stop databases with stop_ovn_daemon()

Wait for the databases to actually exit before returning to
the caller of ovn-ctl. In containerized use-cases the container
runtime often kills the container when the process calling
ovn-ctl exits, which may not give the DBs time to clean up
after themselves.

Reported-at: https://bugzilla.redhat.com/1944239

Signed-off-by: Dan Williams <dcbw at redhat.com>
Signed-off-by: Numan Siddique <numans at ovn.org>
Acked-by: Mark Michelson <mmichels at redhat.com>
(cherry picked from commit f4b44655ec8f721c0b3a88969f683488ef60ce3d)


  Commit: ef0cff409346db3b929d0090beee589c008f6d11
      https://github.com/ovn-org/ovn/commit/ef0cff409346db3b929d0090beee589c008f6d11
  Author: Lorenzo Bianconi <lorenzo.bianconi at redhat.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M tests/ovn-northd.at
    M utilities/ovn-nbctl.c

  Log Message:
  -----------
  ovn-nbctl: dump next-hop for router policies

Commit 35b00c7e79 ('northd: Add ECMP support to router policies.')
introduced 'nexthops' column in the Logical_Router_Policy table to
support ECMP for router policies however print_routing_policy() still
dumps legacy 'nexthop' column as policy next hop.
Fix the issue dumping 'nexthops' columns.

Fixes: 35b00c7e79 ('northd: Add ECMP support to router policies.')
Acked-by: Mark Michelson <mmichels at redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi at redhat.com>
Signed-off-by: Numan Siddique <numans at ovn.org>
(cherry picked from commit d8b282b2852e2b0d4e44963b3b9ade8d28a0b899)


  Commit: 26ad851c69f64a6a0a06f7d331f402e6f0540b70
      https://github.com/ovn-org/ovn/commit/26ad851c69f64a6a0a06f7d331f402e6f0540b70
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2021-04-21 (Wed, 21 Apr 2021)

  Changed paths:
    M controller-vtep/gateway.c

  Log Message:
  -----------
  ovn-controller-vtep: Set chassis_name for newly created Encap.

Without this ovn-controller-vtep fails to register new chassis when RBAC
is enabled.

Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2021-April/382207.html
Reported-by: Odintsov Vladislav <VlOdintsov at croc.ru>
Fixes: d06760b64276 ("ovn: Restrict encap modification to its creating chassis")
Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Acked-by: Mark Michelson <mmichels at redhat.com>
Tested-by: Vladislav Odintsov <odivlad at gmail.com>
Signed-off-by: Numan Siddique <numans at ovn.org>
(cherry picked from commit f9a4c68373b1e4d32e1f027f7f4fdf154878dcc6)


Compare: https://github.com/ovn-org/ovn/compare/36276f75d5b4...26ad851c69f6


More information about the git mailing list