On Sun, Aug 21, 2016 at 4:02 PM, Justin Pettit <jpet...@ovn.org> wrote:
> > > 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. Agreed. > > > 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. > Thanks for the feedback! If we move to etcd, I imagine we'll have to provide another set of upgrade tooling. It would be more ideal to wait for that to solve this issue, but I feel that's going to be too late for the primary potential user motivating this work for me. That's why I wanted to explore how bad it would be to do it now. It feels like if we can make ovn-controller read-only, the only db-specific functionality needed is making ovsdb-server accept connections with read-only access. That seems like a generally useful feature for ovsdb-server, even if we don't use it long term. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
