Oops, I forgot to follow up on this ... On Thu, Dec 22, 2016 at 12:21 AM, Ben Pfaff <b...@ovn.org> wrote:
> On Wed, Dec 21, 2016 at 10:56:35PM -0500, Russell Bryant wrote: > > On Wed, Dec 21, 2016 at 5:06 PM, Ben Pfaff <b...@ovn.org> wrote: > > > > > On Wed, Dec 07, 2016 at 02:28:13PM -0500, Russell Bryant wrote: > > > > Signed-off-by: Russell Bryant <russ...@ovn.org> > > > > > > This procedure isn't what I expected. It recommends: > > > > > > 1. Upgrade SB/NB databases and northd. > > > 2. Upgrade ovn-controller. > > > 3. Upgrade integration. > > > > > > I think that this is likely to cause problems in the common case, > > > because the new northd is likely to try to start using features that > are > > > not yet available on the hypervisors, such as new logical match fields > > > and actions. > > > > > > I expected: > > > > > > 1. Upgrade ovn-controller. > > > 2. Upgrade SB/NB databases and northd. > > > 3. Upgrade integration. > > > > > > (I don't think that it matters when the databases are upgraded, though, > > > as long as they're upgraded before northd.) > > > > > > > Thanks for the feedback! > > > > There's a possible problem in this case, too. ovn-controller could try > to > > start using new fields in the southbound database that aren't there yet. > > I guess that I have always considered that ovn-controller needs to > tolerate some version-related variation in the database schema. This is > a familiar problem, since ovs-vsctl and (to a lesser extent) > ovs-vswitchd also need to tolerate similar variation. > > Different kinds of tolerance must be considered. Missing columns > (because they were added in a later database schema) are one of the > easiest, and the IDL takes care of that for us; the column will just > appear empty. Over in OVS, we normally design the schema so that an > empty column yields the default new behavior anyhow. > > The related_datapaths column that had been proposed for optimizing > conditional monitoring was a tougher case for upgrade. With this > proposal, an empty column or a missing one would break ovn-controller, > since it wouldn't get all of the rows that it needed. Even if the > column was present, it still wouldn't help if ovn-northd was too old to > populate it correctly. I was about to propose that ovn-controller > needed to figure out not just whether the column was present but whether > ovn-northd was new enough and properly populating it, when I came up > with the approach we're now using that doesn't need this column at all. > > So, upgrading the databases earlier cannot hurt, but I doubt that it > solves many problems. > Thanks for the info. > > > Maybe it should be: > > > > 1. Upgrade SB/NB databases. > > 2. Upgrade ovn-controller. > > 3. Upgrade ovn-northd. > > 4. Upgrade integration. > > This ordering seems fine to me. > so we could do the above, or based on your comments: 1. Upgrade ovn-controller. 2. Upgrade databases. 3. Upgrade ovn-northd. 4. Upgrade integration. This one is a little easier to document since 2&3 can be done with a single command, so I'll just document it that way. > Thank you for writing down the upgrade procedure. (Have we written down > the installation procedure?) > No, I don't think so. We have options well documented, but not an OVN install guide. It tends to be covered along with integration guides, though. For example: https://github.com/openvswitch/ovn-kubernetes or http://docs.openstack.org/developer/networking-ovn/install.html but I think a standalone install guide would be good to have, too. -- Russell Bryant _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
