From: Jan Friesse <jfriesse@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] fence_scsi - Configuration file
Date: Thu, 30 Jul 2009 16:08:44 +0200 [thread overview]
Message-ID: <4A71A96C.6080804@redhat.com> (raw)
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.
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
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
Thats more or less everything about design, any comments highly welcomed.
Regards,
Honza
next reply other threads:[~2009-07-30 14:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 14:08 Jan Friesse [this message]
2009-08-03 15:14 ` [Cluster-devel] fence_scsi - Configuration file 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
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=4A71A96C.6080804@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).