On Thu, 19 Jun 2008, Kadlecsik Jozsef wrote:
On Thu, 19 Jun 2008, Fabio M. Di Nitto wrote:
On Wed, 18 Jun 2008, Federico Simoncelli wrote:
On Wed, Jun 18, 2008 at 10:23 AM, Kadlecsik Jozsef
<kadlec@xxxxxxxxxxxxxxx> wrote:
On Wed, 18 Jun 2008, Federico Simoncelli wrote:
Do you think adding a boot parameter (eg: nocluster) could be a good
solution? We should modify the init file for cman to check the
presence of that parameter and skip the start process if present.
We use exactly the same method to specify how to boot a machine:
Do you think we can find a common solution and propose a patch upstream?
I am open to add patches.
Having a boot parameter (eg: nocluster) to skip cman at boot would be
useful in your case or you really need something more specific to GFS?
Skipping cman would prevent any other cluster service to start (GFS too).
GFS can also run in lock_nolock and that does not require cman.
But that is not an option in a in-production GFS cluster, I believe.
There is really nothing that stops you to have / on GFS lock_nolock.
I think you want to make sure of what you really want before
enabling/disabling cman.
What we implemented serves multiple purposes:
a. disable the whole GFS cluster suite (and every service relying on GFS)
for the next reboot of a host as a planned maintenance mode
b. disable the mounting of GFS volumes (and every services relying on GFS
volumes) for the next reboot of a host as a planned maintenance mode
c. boot a host directly in a) mode in case of emergency
d. boot a host directly in b) mode in case of emergency
To underline the difference and importancy of a-c and b-d modes, just a
few examples:
- due to the hardware upgrade of the shared block devices (in our case
Coraid AoE), we applied a) to shut down the whole cluster, upgrade the
hardware, test AoE access and update manually /etc/cluster/cluster.conf
with the new fencing parameters
- once we were hit by a firmware bug in the shared devices and by
switching to b-d) we could run gfs_fsck on all volumes easily
- all modes were used at testing services, fixing boot/shutdown/reboot
init scripts on test nodes (we run GFS on top of Ubuntu).
I understand the use cases. That's not the problem. I'd like to see a
"standard" set of keywords to use that we all agree upon.
As we rewrote the cman and gfs init scripts due to the differences between
RedHat and Debian/Ubuntu, I can't really send patches.
I maintain the Ubuntu init script and work very closely with the Debian
maintainers. At the same time i can apply changes to whatver is shipped
from upstream.
So this is not a blocker whatsoever.
Whatever changes you have, best to have them sent to this mailing list for
evaluation and mostlikely inclusion if they are valid.
But the changes in
question are actually minimal: both the cman and gfs init script starts
with the added lines
#
# Skip GFS if asked at boot time
#
[ "$1" = "start" -a -e /etc/cluster/skip_gfs ] && exit 0
and there is just one more line added to the gfs init script, before
mounting the volumes
[ -e /etc/cluster/skip_gfs_mount ] && exit 0
echo -n "Mounting GFS filesystems: "
mount -a -t gfs
The files /etc/cluster/skip_gfs and /etc/cluster/skip_gfs_mount are
created by the attached init script called 'cluster_maintenance' if
it's called manually by the proper arguments or at boot time when it
detects the corresponding boot arguments (started before cman by init).
The script can run additional scripts to disable/enable services which
rely on GFS.
I see. I think i would prefer to see the parsing of cmdline done directly
by cman/gfs/rgmanager init scripts rather than an extra one.
Few reasons:
- more init scripts increase complexity of boot sequence
- you touch files in /etc and that's not good practise. / might be read
only if we are in emergency maintainance and even if it is read-write,
something that is not really a config option, should go in either
/var/lib/something (if needs to be persistent at reboot) or /tmp.
I hope it helps.
absolutely.
Thanks
Fabio
--
I'm going to make him an offer he can't refuse.
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
