> On Aug 16, 2016, at 6:52 AM, Russell Bryant <rbry...@redhat.com> wrote: > > Thanks for starting this discussion. > > I do think making ovn-controller a read-only client of the database seems > like the simplest path forward. We should pursue that until we hit a > strong reason not to. > > One of the biggest questions remaining for me is how we deal with backwards > compatibility. Whatever we do here will have to account for what happens > for environments running OVN from OVS 2.6 when they upgrade. > > Perhaps the most straight forward way to do that is to make this new more > secure mode optional and off by default. The downside is that it makes the > system more complex, since it will have different modes it can work.
I think we should avoid providing two modes if at all possible. As you mentioned, it increases the complexity, which will likely make it more difficult to test thoroughly and deploy consistently. > An alternative would be to provide some tooling to assist with the upgrade: > > - Document the new requirements for creating Chassis and Encap rows > manually > > - Provide an upgrade tool (via ovn-nbctl/ovn-sbctl/something-else) that > will add the "chassis" option to logical ports set based on where ports are > currently bound in the southbound database. > > - Provide an upgrade tool that converts the MAC_Binding table to whatever > the new chassis local storage for that information would be. I think the tool approach is better. I imagine people deploying 2.6 will be pretty closely tied to the community still, so walking them through an upgrade shouldn't be too bad--especially if we make it easy. Obviously, we'll try to avoid the need for that again in the future. --Justin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
