Message ID | 1542137159-73672-1-git-send-email-hzhou8@ebay.com |
---|---|
State | Superseded |
Headers | show |
Series | [ovs-dev,v2] ovn-sb.ovsschema: Avoid duplicated IPs in Encap table. | expand |
On Tue, Nov 13, 2018 at 11:25:59AM -0800, Han Zhou wrote: > From: Han Zhou <hzhou8@ebay.com> > > 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> I'm worried that this will make it hard for users to upgrade: if they have any duplicate chassis, then they will have to manually delete them before ovsdb-server will accept the new database. I think you mentioned that ovn-controller can't delete the duplicates because of RBAC permissions. What if ovn-northd deletes them instead? If it doesn't have a way to know which one is the "correct" one, it could just delete all of the duplicates, since the ovn-controller that is actually running will re-create its chassis if it disappears.
On Thu, Nov 15, 2018 at 9:24 AM Ben Pfaff <blp@ovn.org> wrote: > > On Tue, Nov 13, 2018 at 11:25:59AM -0800, Han Zhou wrote: > > From: Han Zhou <hzhou8@ebay.com> > > > > 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> > > I'm worried that this will make it hard for users to upgrade: if they > have any duplicate chassis, then they will have to manually delete them > before ovsdb-server will accept the new database. > > I think you mentioned that ovn-controller can't delete the duplicates > because of RBAC permissions. What if ovn-northd deletes them instead? > If it doesn't have a way to know which one is the "correct" one, it > could just delete all of the duplicates, since the ovn-controller that > is actually running will re-create its chassis if it disappears. Hi Ben, as discussed in today's meeting, I sent v3 with NEWS updated. https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/353973.html
diff --git a/ovn/ovn-sb.ovsschema b/ovn/ovn-sb.ovsschema index 5b9537f..afa9859 100644 --- a/ovn/ovn-sb.ovsschema +++ b/ovn/ovn-sb.ovsschema @@ -1,7 +1,7 @@ { "name": "OVN_Southbound", - "version": "1.17.0", - "cksum": "3217981733 15045", + "version": "1.18.0", + "cksum": "910560265 15086", "tables": { "SB_Global": { "columns": { @@ -50,7 +50,8 @@ "min": 0, "max": "unlimited"}}, "ip": {"type": "string"}, - "chassis_name": {"type": "string"}}}, + "chassis_name": {"type": "string"}}, + "indexes": [["type", "ip"]]}, "Address_Set": { "columns": { "name": {"type": "string"},