From: Ryan O'Hara <rohara@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] fence_scsi - Configuration file
Date: Mon, 3 Aug 2009 11:19:44 -0500 [thread overview]
Message-ID: <20090803161944.GD26317@redhat.com> (raw)
In-Reply-To: <4A77035F.60209@redhat.com>
On Mon, Aug 03, 2009 at 05:33:51PM +0200, Jan Friesse wrote:
> Ryan O'Hara napsal(a):
>> What happens if we list devices and have auto_detect set to 'on'? Will
>> we ignore the devices? With this auto_detect parameter, it seems that
>> it will have to be explicitly set to 'off' and devices will have to be
>> listed if we want to avoid auto-detect. Also, what happens if I set
>> auto_detect to 'off' and I don't list any devices?
>>
>
> autodetect set to "on" can have one of these two consequences:
> - Ignore listed device - read only global sections for parameters
^^ I think this is the most logical thing to do.
> - Ignore listed device but use per device parameters in case we will
> find this device by old method - This is what is implemented now
> - Use merge of listed devices and autodetected device
>
> autodetect is by default off. When we not have config file, it will
> become on. When no devices is listed -> we turn it on
Shouldn't auto_detect be default on? We want fence_scsi to work like
it does now unless it is configured otherwise. I was thinking ...
- If not config file exists, auto_detect is on.
- If a config file does exists and auto_detect is not defined to be
off, auto_detect should default to on ... regardless of whether or
not any devices are listed.
> I hope nobody will ever set autodetect to off and don't list any device,
> but we can do two things:
> - Ignore this flag and use vgs (this is what code does now)
> - Do what user want -> no device fencing
If this evern happens, the node will not register with any
devices. There are two possible outcomes:
1. If a reservation already exists (being held by another node/key),
the node in question won't have write access to the device(s) since it
didn't register with anything.
2. If a reservation does not already exist, nothing changes and the
node is completely unprotected and there is no way to fence it.
I suppose there is a third case where the node is already registered,
so doing nothing is valid, but this is just pure luck.
next prev parent reply other threads:[~2009-08-03 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 14:08 [Cluster-devel] fence_scsi - Configuration file Jan Friesse
2009-08-03 15:14 ` Ryan O'Hara
2009-08-03 15:33 ` Jan Friesse
2009-08-03 16:19 ` Ryan O'Hara [this message]
2009-08-04 11:14 ` Jan Friesse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090803161944.GD26317@redhat.com \
--to=rohara@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.