[ClusterLabs Developers] Thinking about OCF 1.2: fence agents etc.

[Ken Gaillot]

Hi all,

The OCF Resource Agent API 1.1 is still fresh out of the oven, but I'm
thinking ahead to 1.2.

In the past, we've talked about putting the fence agent API under the
OCF umbrella (currently the fence agent API is just a write-up in the
fence-agents project). More recently, the idea of storage agents has
come up, to control external storage replication from cluster nodes.

I'm thinking we could add "agent types" to the OCF standard. A subset
of the standard would apply to all types (for example, the basic meta-
data format). The rest of the current standard would become the
"service" type (for example, start/stop/status actions), and we could
add new types for fence agents and so forth.

On the pacemaker side, the ocf:PROVIDER:AGENT syntax could expand to
ocf:TYPE:PROVIDER:AGENT, with TYPE defaulting to "service" so that the
old syntax is still valid. For example

  ocf:service:heartbeat:IPaddr2 (or ocf:heartbeat:IPaddr2)
  ocf:fence:clusterlabs:ipmi (instead of stonith:fence_ipmi)
  ocf:storage:clusterlabs:emc

Existing resource agents wouldn't need any changes. Fence agents should
maybe become more OCF-like, but we could create library helpers to make
backward compatibility easy.

Pacemaker's health agents (currently just typical OCF agents) could
become a new type as well, e.g. ocf:health:pacemaker:cpu instead of
ocf:pacemaker:HealthCPU. The agents would stay essentially the same,
but grouping them would make it easier for Pacemaker and front-ends to
treat them specially.

Currently, resource agents go in
/usr/lib/ocf/resource.d/PROVIDER/AGENT. I'm thinking fence.d,
storage.d, and health.d could parallel resource.d.

I wanted to run this idea by everyone here before taking it to the
users list. Does this sound worthwhile? Is there anything I'm
forgetting or overlooking?
-- 
Ken Gaillot <kgaillot at redhat.com>