diff options
| author | Han Zhou <hzhou8@ebay.com> | 2018-12-18 14:18:34 -0800 |
|---|---|---|
| committer | Ben Pfaff <blp@ovn.org> | 2018-12-27 11:45:27 -0800 |
| commit | b6413ae4728e94d1656e0769910afcccae116f59 (patch) | |
| tree | 116dc8bab59574e6a0321421daffcd2e95528f80 /Documentation/intro | |
| parent | eca4cde025f7f061973fd1c511c34344ce57acd0 (diff) | |
| download | openvswitch-b6413ae4728e94d1656e0769910afcccae116f59.tar.gz | |
ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.
When adding a new chassis, if there is an old chassis with same IP
existed in Encap table, it is allowed to be added today. However,
allowing it to be added results in problems:
1. The new chassis cannot work because none of the other chassises
are able to create tunnel to it, because of the IP confliction
with already existed tunnel to the old chassis.
2. All the other chassises will continuously retry creating the tunnel
and complaining about the error.
So, instead of hiding the problem, it is better to expose it while
trying to add the second chassis with duplicated IP. This patch
ensures it from the ovsdb schema.
Signed-off-by: Han Zhou <hzhou8@ebay.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Diffstat (limited to 'Documentation/intro')
| -rw-r--r-- | Documentation/intro/install/ovn-upgrades.rst | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/Documentation/intro/install/ovn-upgrades.rst b/Documentation/intro/install/ovn-upgrades.rst index 0b76c96f9..3e6cd984e 100644 --- a/Documentation/intro/install/ovn-upgrades.rst +++ b/Documentation/intro/install/ovn-upgrades.rst @@ -75,6 +75,34 @@ or if you're using a Linux distribution with systemd:: $ sudo systemctl restart ovn-northd +Schema Change +^^^^^^^^^^^^^ + +During database upgrading, if there is schema change, the DB file will be +converted to the new schema automatically, if the schema change is backward +compatible. OVN tries the best to keep the DB schemas backward compatible. + +However, there can be situations that an incompatible change is reasonble. An +example of such case is to add constraints in the table to ensure correctness. +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. + +#. 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 + + Then delete the chassis with command:: + + $ ovn-sbctl chassis-del <chassis> + + Upgrading OVN Integration ------------------------- |