Hi,
Thank you very very much for your quick action, Dejan!!
Dejan Muhamedagic wrote:
On Fri, Sep 19, 2008 at 05:28:42PM +0200, Andrew Beekhof wrote:
On Fri, Sep 19, 2008 at 16:44, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote:
Hi,
On Fri, Sep 19, 2008 at 11:17:34AM +0200, Andrew Beekhof wrote:
On Fri, Sep 19, 2008 at 09:00, Satomi TANIGUCHI
<[EMAIL PROTECTED]> wrote:
[snip]
If you _really_ want to have a per-plugin value, I suggest making it
an extra resource parameter (ie. like hostlist) and teach stonithd to
look for and use it _instead_of_ the CRM-supplied value.
Dejan: Any objections to something like this?
No.
Cascaded stonith setup can be realized by setting two or more plugins in a
group
at the moment.
I don't think so. Currently, all stonith plugins (coming from
various stonith resources) are tried in turn until one succeeds,
but there is no ordering. The information about them being
grouped is lost, i.e. stonithd has no idea which stonith plugin
should be invoked first. Another option (attribute) would have to
be implemented, something like "priority".
OK, I see.
As far as I confirm, if the first plugin in a group is failed,
the second one is executed.
And if the first one succeeds, the second one is _not_ executed.
Right.
If it is an unexpected behavior, please let me know the correct one.
Cool. I had no idea. I, like the CRM, am blissfully ignorant of how
STONITHd works :-)
Good for you :)
To summarize, we'd need the following new features:
- stonith plugin priority (ordering of stonith resources) (stonithd)
ack
This is implemented in the development branch:
http://hg.clusterlabs.org/pacemaker/dev/rev/a3a62aa43d64
The priorities are set with the "priority" instance attribute.
The lower the number, the higher the priority.
It worked pretty well with my quick check.
Many thanks!
- fencing operation timeouts per stonith resource (stonithd)
ack
http://hg.clusterlabs.org/pacemaker/dev/rev/0f17d8472570
http://hg.clusterlabs.org/pacemaker/dev/rev/785fb0d9d821
The timeouts are taken from the "start" operation. Even though it
may not be obvious that this timeout is used for the fencing
operations as well, I think that it still makes more sense than
making an extra instance attribute. Any objections?
Maybe, users are at a loss what to do when they want to set fence op's timeout,
I think.
Adding "stonith-timeout" in <instance_attributes> seems to be a better way...
(adding "stonith" or "fence" operation in <operations> is an exaggerated way?)
Satomi-san: It would be great if you can test these changes with
your setup.
Certainly, with pleasure!
I'm doing now.
- global fencing timeout (crm cluster property)
Or, we totally ignore this and rely solely on the per-resource value above.
I'd vote for that for the sake of consistency (otherwise its
non-obvious which value takes precedence)
That's how it works right now. The users should take care of
setting the cluster_delay properly, i.e. to the maximum possible
stonith timeout and then double that. Right?
All right.
BTW, it would probably be a good idea to have a stonith specific
property. cluster_delay is namewise (and descriptionwise) a bit
far fetched.
I agree.
But if it is possible, the value for this should be calculated automatically
based on each stonith plugin, I think.
Because an user does make a mistake.
The global fencing timeout would have to be set either to the
total of single timeouts or maximum timeout depending on the
nature of devices.
Any objections or pitfalls?
The timing... if people want this for 1.0, then someone needs to get a
patch to me by the 24th (Wednesday) at the latest.
There'll be no more features after then (bugfixes are of course ok,
just no new features).
On time.
Thanks again!
Thanks,
Dejan
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
Best Regards,
Satomi TANIGUCHI
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
