[Cluster-devel] fence_scsi - Configuration file

[Ryan O'Hara <rohara@redhat.com>]

On Thu, Jul 30, 2009 at 04:08:44PM +0200, Jan Friesse wrote:
> I was working on fence_scsi configuration file and will be very happy
> for opinions of larger audience for syntax/semantic.
> 
> Syntax:
> Basically it's little improved corosync.conf so example:
> 
> # Comment line
> 
> # ^^^ white lines ignored
> 
> # Definition of device
> /dev/sda
> 
> # Can be more
> /dev/sdb
> /dev/sdc
> 
> # Configuration section -> everything what doesn't start with /dev/
> global {
>   key1: value
>   key2: value
> }
> 
> # Device definition + per device configuration
> /dev/sdd {
>   key1: value
> }
> 
> ### CUT HERE ####
> 
> This syntax should give us very flexible background for future
> additions. On the other hand, it allows user to overwrite vgs
> auto_detection by simple list of device.

Right. I'd also like to point out that this config file will need to
be manually replicated to all node in the cluster if a user wants to
explicitly list which devices to use.

> Now something about semantic (what is more important).
> 
> What I think is good to have is support for hierarchy of options
> processed in this way:
> 1) Hardcoded defaults in fence_scsi - Used in case nobody will say
> something different
> 2) global device options - Used for all devices listed (and maybe auto
> detected, will be discussed later)
> 3) Per device configuration options
>
> So I will try to give example for APTPL flag. This is typical flag,
> where we want to be by default enabled or disabled (really don't care
> and should be point of discussion) and we want give user ability to
> change it and maybe change it for some devices differently. So for
> example, user has:
> - First array - supports APTPL
> /dev/sda
> /dev/sdb
> - Second array - Doesn't support APTPL
> /dev/sdc
> 
> and default hardcoded in fence_scsi is to NOT use APTPL:
> 
> In my point of view, user can use:
> 
> ### Cut HERE
> global {
>   aptpl: on
> }
> 
> /dev/sda
> /dev/sdb
> /dev/sdc {
>   aptpl: off
> }
> ### CUT HERE
> 
> OR
> 
> ### Cut HERE
> /dev/sda {
>   aptpl: on
> }
> /dev/sdb {
>   aptpl: on
> }
> # CUT HERE

I'm ok with this, but I'm not sure that having 2 arrays, one that
supports APTPL and one that does not, would be useful. Only in the
case where the array that did support it lost power ... but the one
that did not support it remained on ... would you see it being
useful. Still, if people was to do this I suppose it is ok.
 
> Next, in my design is global variable auto_detect. In case, auto_detect
> is on, we are using OLD method (vgs scanning) and use per device
> options. So another example. Now user has only one array, supporting
> APTPL and default is to NOT use APTPL. User DON'T want to enter devices,
> so can use:
> ### CUT HERE
> global {
>   auto_detect: on
>   aptpl: on
> }
> ### CUT HERE

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?

Ryan