The LocalResourceManager been requested to model fencing operations as resource operations.
AlanRobertson: I think this sounds like a big win if we can do this, but as of now, I'm not 100% sure if we know we can do this. More details on this can be found in the NodeFencing page. Also, for some reason, I thought this might also include ResourceFencing (since, after all, our main object is a resource). So, this is unclear to me at the moment.
HuangZhen: what is the define of ResourceFencing? As my understanding, it means that if the "stop" operation does not work or needs a long time to finish, we can use "fence" operation to stop the resource immediately. If so, it is the RA do the final work of ResourceFencing. LRM will just add a type of operation.
LarsMarowskyBree: I do not think ResourceFencing needs to be handled specially by the LocalResourceManager. Either a resource is self-fencing, in which case we just start it up, knowing that it will handle all of it internally (and the monitor/status operation would inform us if a reservation was pulled out from under us), or we need to perform a special 'reserve' command - but I would argue that we should encapsulate this into a special ResourceAgent, say SCSIReservation, which the Filesystem resource would then depend on - from the point of view of the LRM, no special handling at all is required for either of these two.
LarsMarowskyBree: Picking up this discussion, we have not seen any great objection to modelling a STONITH controller as a resource. I'll try to summarize the discussion:
To make sure there's no confusion between the resource agents and the StonithAgents, they will be mapped to a special resource class stonith in addition to ocf, lsb, heartbeat etc. They will also be searched for in a different path. See the StonithAgent page for a detailed list of differences etc.
But essentially, they provide an additional fence operation via which we can ask them to shot a given set of nodes and report back the result.
This has the advantage that we can monitor the STONITH device using the regular monitor code path and find out early on when a STONITH device becomes unuseable.
From the LocalResourceManager point of view, this seems to be fairly straight-forward. The only real change is searching for the stonith class agents in a different path; everything else should just work. Right?