[ClusterLabs] Need advice: deep pacemaker integration, best approach?

alexey at pavlyuts.ru alexey at pavlyuts.ru
Sun Jun 9 16:13:09 EDT 2024


Hi All,

 

We intend to integrate Pacemaker as failover engine into a very specific
product. The handmade prototype works pretty well. It includes a couple of
dozens coordinated resources to implement one target application instance
with its full network configuration. The prototype was made with pcs shell,
but the process is very complex and annoying for mass- rollout by field
engineers.

 

Our goal is to develop a kind of configuration shell to allow a user to
setup, monitor and manage app instance as entities, not as a set of cluster
resources. Means, user deals with app settings and status, the shell
translates it to resources configuration and status and back.

 

The shell be made with Python, as it is the best for us for now. The
question for me: what is the best approach to put Pacemaker under the
capote. I did not consider to build it over pcs as pcs output quite hard to
render, so I have to use more machine-friendly interface to pacemaker for
sure but the question is which ones fits our needs the best.

 

It seems like the best way is to use custom resource agents, XML structures
and cibadmin to manage configuration and get status information. However, it
is not clean: should cibadmin be used exclusively, or there also other API
to pacemaker config pull/push?

 

Also, it is not clear how to manage resource errors and cleanup? Are there
other ways that call to crm_resource for cleanup and failed resource
restart? Could it be made via CIB manipulation like force lrm history
records delete? 

 

I understand that the source is the ultimate answer for any question, but I
will be very grateful for any advice from ones who has all the answers on
their fingertips.

 

Thank you in advance for sharing your thoughts and experience!

 

Sincerely,

 

Alex

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20240609/883137a2/attachment.htm>


More information about the Users mailing list