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 <kgail...@redhat.com> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/