All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Friesse <jfriesse@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] fence_scsi - Configuration file
Date: Tue, 04 Aug 2009 13:14:11 +0200	[thread overview]
Message-ID: <4A781803.2060209@redhat.com> (raw)
In-Reply-To: <20090803161944.GD26317@redhat.com>

Ryan,

Ryan O'Hara wrote:
> 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.

I think first or second are more or less same. It's matter of line with
%device_params_list = ();. Maybe we can make this configurable...

> 
>> - 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.
> 

- Interesting idea... I'm little fear about BZs like "fence_scsi ignores
my devices listed in config file, ..."

>> 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.
> 

I'm really not sure what to do in this case and turning on autodetection
seems to me like a not so bad idea.

Anyway, it looks like we are still standing on one place, so what about
just do this:
- Remove per device options
- Remove all flags and config sections (it looks like they are not needed)
- Let it be as a simple list with [/dev/device\n]* (+ comments)

?

Syntax is ready for future bigger things and parsing code will remain
same -> future additions should be simple. I will just remove (or
ignore) some variables. Thats simple

Regards,
  Honza



      reply	other threads:[~2009-08-04 11:14 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
2009-08-04 11:14       ` Jan Friesse [this message]

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=4A781803.2060209@redhat.com \
    --to=jfriesse@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.