[ovs-dev] [PATCH v4] ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.

Ben Pfaff blp at ovn.org
Thu Dec 27 19:44:08 UTC 2018


On Wed, Dec 12, 2018 at 10:22:53PM -0800, Han Zhou wrote:
> On Wed, Dec 12, 2018 at 12:05 PM Ben Pfaff <blp at ovn.org> wrote:
> >
> > On Thu, Nov 15, 2018 at 05:21:47PM -0800, Han Zhou wrote:
> > > From: Han Zhou <hzhou8 at 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 at ebay.com>
> >
> > This seems reasonable, but should we change the schema version number
> > from 1.17.0 to 2.0.0 because of the incompatibility?
> >
> Hmm, it is potentially incompatible, if there is *dirty* data already in
> the old system. However it is not like changes that is obviously
> incompatible such as deleting a column.
> In this case I am not sure if the major version should be increased or not.
> Is there a guideline for this?

I don't know a reason to not increment the major version.  It is a
useful way to let alert people know of a potential incompatibility, and
there is no obvious downside.  I'd prefer to increment it.


More information about the dev mailing list