On Wed, Dec 12, 2018 at 10:22:53PM -0800, Han Zhou wrote: > On Wed, Dec 12, 2018 at 12:05 PM Ben Pfaff <[email protected]> wrote: > > > > On Thu, Nov 15, 2018 at 05:21:47PM -0800, Han Zhou wrote: > > > From: Han Zhou <[email protected]> > > > > > > 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 <[email protected]> > > > > 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
