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

Vladislav Bogdanov bubble at hoster-ok.com
Tue Oct 12 12:51:01 EDT 2021


Hi!
At the first glance looks great.

Best,
Vladislav

On October 12, 2021 7:43:28 PM Ken Gaillot <kgaillot at redhat.com> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20211012/b1d53c6b/attachment.htm>


More information about the Developers mailing list