Alan Robertson wrote me:
>
> Is there a URL for grits, et al?
>
Everything that's public is in the linux-ha-dev list
archive on tummy.
I have been underwhelmed by feedback, and am contemplating
serious reductions in capability in the interests of
simplicity and correctness. I am thinking that it
ought to provide clean access to STOMITH done via
rc power switch, agent-on-machine, and via SAN storage
fencing. It may not need to provide anything other
than total node-level granularity. The per-resource
capability in GRITS seems too complicated, in retrospect.
The GFS people have just yesterday floated a STOMITH
config proposal. It may be a place to start. I think
something between that (which was flat config file only)
and GRITS might be the sweet spot. I believe we need
protocol for interoperability, and at least agreement
on the right verb set from which to form an API. I'm
not sure it's good to do "the" API yet, because I see
call for several flavors -- at least synchronous and
asyncronous have applications. (In the general case
of an N node cluster having partitioned, you'd want the
surviving quorum to fence off the entire losing subset;
async interfaces would be better for that. you'd start
the fences against all the nodes, wait for all
the completions, then proceed in knowledge they had
been neutralized.)
-dB
>
> Is there a URL for grits, et al?
>
Everything that's public is in the linux-ha-dev list
archive on tummy.
I have been underwhelmed by feedback, and am contemplating
serious reductions in capability in the interests of
simplicity and correctness. I am thinking that it
ought to provide clean access to STOMITH done via
rc power switch, agent-on-machine, and via SAN storage
fencing. It may not need to provide anything other
than total node-level granularity. The per-resource
capability in GRITS seems too complicated, in retrospect.
The GFS people have just yesterday floated a STOMITH
config proposal. It may be a place to start. I think
something between that (which was flat config file only)
and GRITS might be the sweet spot. I believe we need
protocol for interoperability, and at least agreement
on the right verb set from which to form an API. I'm
not sure it's good to do "the" API yet, because I see
call for several flavors -- at least synchronous and
asyncronous have applications. (In the general case
of an N node cluster having partitioned, you'd want the
surviving quorum to fence off the entire losing subset;
async interfaces would be better for that. you'd start
the fences against all the nodes, wait for all
the completions, then proceed in knowledge they had
been neutralized.)
-dB