[ovs-dev] [PATCH v2] debian: force-reload-kmod while package upgrading.

Gurucharan Shetty shettyg at nicira.com
Tue Apr 23 00:10:21 UTC 2013


On Mon, Apr 22, 2013 at 2:19 PM, Ben Pfaff <blp at 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 <gshetty at 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.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20130422/f80ad86c/attachment-0003.html>


More information about the dev mailing list