[ovs-git] [openvswitch/ovs] 87cef7: ovn-controller: Fix chassis ovn-sbdb record init

Dumitru Ceara noreply at github.com
Mon Jul 8 21:05:40 UTC 2019


  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: 87cef708f7e1092ec39a9414e4a15ee5a97bb051
      https://github.com/openvswitch/ovs/commit/87cef708f7e1092ec39a9414e4a15ee5a97bb051
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2019-07-08 (Mon, 08 Jul 2019)

  Changed paths:
    M ovn/controller/chassis.c
    M ovn/controller/chassis.h
    M ovn/controller/ovn-controller.c
    M tests/ovn-controller.at

  Log Message:
  -----------
  ovn-controller: Fix chassis ovn-sbdb record init

The chassis_run code didn't take into account the scenario when the
system-id was changed in the Open_vSwitch table. Due to this the code
was trying to insert a new Chassis record in the OVN_Southbound DB with
the same Encaps as the previous Chassis record. The transaction used
to insert the new records was aborting due to the ["type", "ip"]
index constraint violation as we were creating new Encap entries with
the same "type" and "ip" as the old ones.

In order to fix this issue the flow is now:
1. the first time ovn-controller initializes the Chassis (shortly after
start up) we store the chassis-id.
2. for subsequent chassis_run calls we use last configured
chassis-id stored at the previous step to lookup the old Chassis record.
3. when ovn-controller shuts down gracefully we lookup the Chassis
record based on the chassis-id stored in memory at steps 1 and 2 above.
This is to avoid failing to cleanup the Chassis record in OVN_Southbound
DB if the OVS system-id changes between the last call to chassis_run and
chassis_cleanup.

Reported-at: https://bugzilla.redhat.com/1708146
Reported-by: Haidong Li <haili at redhat.com>
Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Signed-off-by: Ben Pfaff <blp at ovn.org>


  Commit: 242f1799fc2271747f06f732158c95412ef2ca98
      https://github.com/openvswitch/ovs/commit/242f1799fc2271747f06f732158c95412ef2ca98
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2019-07-08 (Mon, 08 Jul 2019)

  Changed paths:
    M ovn/controller/chassis.c
    M ovn/controller/ovn-controller.c

  Log Message:
  -----------
  ovn-controller: Refactor chassis.c to abstract the string parsing

Abstract out the chassis config string processing and use library data
structures (e.g., sset).
Rename the get_chassis_id function in ovn-controller.c to
get_ovs_chassis_id to avoid confusion with the newly added
chassis_get_id function from chassis.c which returns the last
successfully configured chassis-id.

Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Signed-off-by: Ben Pfaff <blp at ovn.org>


  Commit: c18c020e3cf789fbf5f3fc96e02fee4fc94c789c
      https://github.com/openvswitch/ovs/commit/c18c020e3cf789fbf5f3fc96e02fee4fc94c789c
  Author: Dumitru Ceara <dceara at redhat.com>
  Date:   2019-07-08 (Mon, 08 Jul 2019)

  Changed paths:
    M ovn/controller/chassis.c
    M ovn/controller/chassis.h
    M ovn/controller/ovn-controller.c

  Log Message:
  -----------
  ovn-controller: Update stale chassis entry at init

The first time ovn-controller initializes the Chassis entry (shortly
after start up) we first look if there is a stale Chassis record in the
OVN_Southbound DB by checking if any of the old Encap entries associated
to the Chassis record match the new tunnel configuration. If found it
means that ovn-controller didn't shutdown gracefully last time it was
run so it didn't cleanup the Chassis table. Potentially in the meantime
the OVS system-id was also changed. We then update the stale entry with
the new configuration and store the last configured chassis-id in memory
to avoid walking the Chassis table every time.

Signed-off-by: Dumitru Ceara <dceara at redhat.com>
Signed-off-by: Ben Pfaff <blp at ovn.org>


Compare: https://github.com/openvswitch/ovs/compare/080f080c3bc1...c18c020e3cf7


More information about the git mailing list