Mailing List Archive

On 2014-02-05T15:06:47, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

> I guess the kernel update is more common than the "just the ocfs2-kmp update"

Well, some customers do apply updates in the recommended way, and thus
don't encounter this ;-) In any case, since at this time the cluster
services are already stopped, at least the service impact is minimal.

> > This would avoid this error too. Or keeping multiple kernel versions in
> > parallel (which also helps if a kernel update no longer boots for some
> > reason). Removing the running kernel package is usually not a great
> > idea; I prefer to remove them after having successfully rebooted only,
> > because you *never* know if you may have to reload a module.
>
> There's another way: (Like HP-UX learned to do it): Defer changes to the
> running kernel until shutdown/reboot.

True. Hence: activate multi-versions for the kernel in
/etc/zypp/zypp.conf and only remove the old kernel after the reboot. I
do that manually, but I do think we even have a script for that
somewhere. I honestly don't remember where though; I like to keep
several kernels around for testing anyway.

I think this is the default going forward, but as always: zypper gained
this ability during the SLE 11 cycle, and we couldn't just change
existing behaviour in a simple update, it has to be manually
activated.


Regards,
Lars

--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

>>> Lars Marowsky-Bree <lmb@suse.com> schrieb am 05.02.2014 um 15:11 in
Nachricht
<20140205141140.GU13514@suse.de>:
> On 2014-02-05T15:06:47, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
wrote:
>
>> I guess the kernel update is more common than the "just the ocfs2-kmp
update"
>
> Well, some customers do apply updates in the recommended way, and thus
> don't encounter this ;-) In any case, since at this time the cluster
> services are already stopped, at least the service impact is minimal.
>
>> > This would avoid this error too. Or keeping multiple kernel versions in
>> > parallel (which also helps if a kernel update no longer boots for some
>> > reason). Removing the running kernel package is usually not a great
>> > idea; I prefer to remove them after having successfully rebooted only,
>> > because you *never* know if you may have to reload a module.
>>
>> There's another way: (Like HP-UX learned to do it): Defer changes to the
>> running kernel until shutdown/reboot.
>
> True. Hence: activate multi-versions for the kernel in
> /etc/zypp/zypp.conf and only remove the old kernel after the reboot. I
> do that manually, but I do think we even have a script for that
> somewhere. I honestly don't remember where though; I like to keep
> several kernels around for testing anyway.
>
> I think this is the default going forward, but as always: zypper gained
> this ability during the SLE 11 cycle, and we couldn't just change
> existing behaviour in a simple update, it has to be manually
> activated.

I did a quick check: It seems only "ocf:ocfs2:o2cb" does sucj (IMHO) nonsense
like removing a module on stop (I can guess it's a leftover from o2cb module
hacking when the developer was too lazy to remove the module by hand when
wanting to try a newer version):
--
# egrep 'modprobe|rmmod' /usr/lib/ocf/resource.d/*/*
/usr/lib/ocf/resource.d/heartbeat/drbd: do_cmd modprobe -s drbd `$DRBDADM
sh-mod-parms` || {
/usr/lib/ocf/resource.d/heartbeat/iface-vlan: error="$(modprobe
8021q 2>&1)"
/usr/lib/ocf/resource.d/linbit/drbd: do_cmd modprobe -s drbd
`$DRBDADM sh-mod-parms` || {
/usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -rs "$FSNAME"
/usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -rs "$MODNAME"
/usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -s ocfs2_stackglue
/usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -s ocfs2_stack_user
/usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -s ocfs2
/usr/lib/ocf/resource.d/pacemaker/controld: modprobe configfs
/usr/lib/ocf/resource.d/pacemaker/controld: modprobe dlm
--

Regards,
Ulrich


>
>
> Regards,
> Lars
>
> --
> Architect Storage/HA
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer,

> HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems


_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 11 Feb 2014, at 10:38 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

>>>> Lars Marowsky-Bree <lmb@suse.com> schrieb am 05.02.2014 um 15:11 in
> Nachricht
> <20140205141140.GU13514@suse.de>:
>> On 2014-02-05T15:06:47, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
> wrote:
>>
>>> I guess the kernel update is more common than the "just the ocfs2-kmp
> update"
>>
>> Well, some customers do apply updates in the recommended way, and thus
>> don't encounter this ;-) In any case, since at this time the cluster
>> services are already stopped, at least the service impact is minimal.
>>
>>>> This would avoid this error too. Or keeping multiple kernel versions in
>>>> parallel (which also helps if a kernel update no longer boots for some
>>>> reason). Removing the running kernel package is usually not a great
>>>> idea; I prefer to remove them after having successfully rebooted only,
>>>> because you *never* know if you may have to reload a module.
>>>
>>> There's another way: (Like HP-UX learned to do it): Defer changes to the
>>> running kernel until shutdown/reboot.
>>
>> True. Hence: activate multi-versions for the kernel in
>> /etc/zypp/zypp.conf and only remove the old kernel after the reboot. I
>> do that manually, but I do think we even have a script for that
>> somewhere. I honestly don't remember where though; I like to keep
>> several kernels around for testing anyway.
>>
>> I think this is the default going forward, but as always: zypper gained
>> this ability during the SLE 11 cycle, and we couldn't just change
>> existing behaviour in a simple update, it has to be manually
>> activated.
>
> I did a quick check: It seems only "ocf:ocfs2:o2cb" does sucj (IMHO) nonsense
> like removing a module on stop (I can guess it's a leftover from o2cb module
> hacking when the developer was too lazy to remove the module by hand when
> wanting to try a newer version):

seems pretty reasonable to me.
stop == remove all trace of the active resource.

> --
> # egrep 'modprobe|rmmod' /usr/lib/ocf/resource.d/*/*
> /usr/lib/ocf/resource.d/heartbeat/drbd: do_cmd modprobe -s drbd `$DRBDADM
> sh-mod-parms` || {
> /usr/lib/ocf/resource.d/heartbeat/iface-vlan: error="$(modprobe
> 8021q 2>&1)"
> /usr/lib/ocf/resource.d/linbit/drbd: do_cmd modprobe -s drbd
> `$DRBDADM sh-mod-parms` || {
> /usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -rs "$FSNAME"
> /usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -rs "$MODNAME"
> /usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -s ocfs2_stackglue
> /usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -s ocfs2_stack_user
> /usr/lib/ocf/resource.d/ocfs2/o2cb: modprobe -s ocfs2
> /usr/lib/ocf/resource.d/pacemaker/controld: modprobe configfs
> /usr/lib/ocf/resource.d/pacemaker/controld: modprobe dlm
> --
>
> Regards,
> Ulrich
>
>
>>
>>
>> Regards,
>> Lars
>>
>> --
>> Architect Storage/HA
>> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer,
>
>> HRB 21284 (AG Nürnberg)
>> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>>
>> _______________________________________________
>> Linux-HA mailing list
>> Linux-HA@lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> See also: http://linux-ha.org/ReportingProblems
>
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

>>> Andrew Beekhof <andrew@beekhof.net> schrieb am 17.02.2014 um 02:33 in Nachricht
<7619A7E9-F006-4098-90F9-5C5B8BC84FB0@beekhof.net>:

> On 11 Feb 2014, at 10:38 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
> wrote:

[...]
>> I did a quick check: It seems only "ocf:ocfs2:o2cb" does such (IMHO)
> nonsense
>> like removing a module on stop (I can guess it's a leftover from o2cb module
>> hacking when the developer was too lazy to remove the module by hand when
>> wanting to try a newer version):
>
> seems pretty reasonable to me.
> stop == remove all trace of the active resource.
>
[...]

But why doesn't the LVM RA try to remove the lvm module, and why doesn't the NFS RA try to remove the nfs module, etc. then?

Regards,
Ulrich


_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

On 17 Feb 2014, at 6:39 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

>>>> Andrew Beekhof <andrew@beekhof.net> schrieb am 17.02.2014 um 02:33 in Nachricht
> <7619A7E9-F006-4098-90F9-5C5B8BC84FB0@beekhof.net>:
>
>> On 11 Feb 2014, at 10:38 pm, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
>> wrote:
>
> [...]
>>> I did a quick check: It seems only "ocf:ocfs2:o2cb" does such (IMHO)
>> nonsense
>>> like removing a module on stop (I can guess it's a leftover from o2cb module
>>> hacking when the developer was too lazy to remove the module by hand when
>>> wanting to try a newer version):
>>
>> seems pretty reasonable to me.
>> stop == remove all trace of the active resource.
>>
> [...]
>
> But why doesn't the LVM RA try to remove the lvm module, and why doesn't the NFS RA try to remove the nfs module, etc. then?

No idea, I didn't write those either. Perhaps they should