On Mon, Apr 22, 2013 at 9:26 PM, Ben Pfaff <b...@nicira.com> wrote:
> On Mon, Apr 22, 2013 at 05:10:21PM -0700, Gurucharan Shetty wrote: > > On Mon, Apr 22, 2013 at 2:19 PM, Ben Pfaff <b...@nicira.com> wrote: > > > > > On Wed, Apr 17, 2013 at 03:11:12PM -0700, Gurucharan Shetty wrote: > > > > Currently, when we upgrade openvswitch packages, we do a restart > > > > of userspace daemons automatically. This does not replace the > > > > kernel module. > > > > > > > > But almost everytime, we want to use the new kernel module > > > > that comes with the new version. This means that we need to > > > > manually do a "force-reload-kmod". This step, reloads the > > > > kernel module and also restarts the userspace daemons. This gives > > > > us a total of two restarts of userspace daemons. This is quite > > > > expensive in a hypervisor with hundreds of VMs sending real traffic. > > > > This also hurts the controller as it gets two reconnections in a > short > > > > amount of time. > > > > > > > > With this patch, during a package upgrade, if the kernel module > > > > on disk is different than the one that is loaded, we will > > > > automatically do a force-reload-kmod while openvswitch-switch > > > > is installed. If not, we will just do a "restart" like before. > > > > > > > > One can install the kernel package first and then install the > userspace > > > > packages in 2 separate steps to enforce a single 'force-reload-kmod'. > > > > > > > > If anyone wants to just restart the userspace package instead of > > > > force-reload-kmod, they can set the value of OVS_FORCE_RELOAD_KMOD=no > > > > while installing the package. > > > > Ex: OVS_FORCE_RELOAD_KMOD=no dpkg -i openvswitch-switch* > > > > > > > > Signed-off-by: Gurucharan Shetty <gshe...@nicira.com> > > > > > > This looks good. > > > > > > The one thing that it makes me wonder is whether we should print (or > > > just log) anything about what decision we're making and why. If > > > something gets screwed up on 1 of 1000 hypervisors, then this might be > > > valuable information in the post-mortem. (Customer: "WTF did this > > > upgrade fail?" me: "...hmm, looks like you somehow installed a kernel > > > module a year too old." versus "...hmm, dunno.") But it all depends > > > on how likely you think these problems are. > > > > > > > Yes. Logging makes sense. I will send v3. I plan to use > > /sys/module/openvswitch/version > > instead of srcversion as logging that gives more meaning. > > I agree that it's more meaningful. But my assumption is that srcversion > changes whenever one modifies the module (I guess it's a hash of the > source code?), whereas version might not. That could be a real surprise > sometimes. > > Perhaps one could consider comparing and logging both version and > srcversion? > Okay. I will compare srcversion. Log both srcversion and version. Sending a v4.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
