use crm_mon instead parsing cib with cibadmin for constraint metric about ha_cluster_exporter HOT 6 OPEN

crm_mon is just an additional layer that parses the CIB itself, why would it be the "cleanest solution"?
What are the shortcomings of parsing the CIB directly?

from ha_cluster_exporter.

It is a discussion i had back in time with @gao-yan and crm_mon should be considered the official tool for getting a right formatted data. Parsing CIB etc, they are plenty of this hacks in hawk.

In this exporter, we are using here cibadmin binary for getting only one metric, the constraint metric.

Instead of maintaining 2 binary tools with different API/ABI breaking changes that we can have, we should consolidate to the crm_mon.

Also could be a nice improvement/contribution upstream to the C code to add this kind of data.

It is more a middle-term issue, but removing a binary dependency is always an improvement if we get the same data from crm_mon (which is the tool we use mostly here)

from ha_cluster_exporter.

I guess we should open an issue on the Pacemaker project to add the feature we require to crm_mon, then. :)
I'm still not entirely sure if the benefits are worth the amount of work this will require; in fact, at some point I thought the other way around: to simplify the exporter, we could just use the CIB and not use crm_mon at all!

from ha_cluster_exporter.

it is a tracking issue which we can reference later on. :)

Parsing the CIB directly has in my knowledge some contra-effects and risks comparing to crm_mon. Maybe @gao-yan could explain more.

I think if there is no contra to parse the CIB directly and it provides the same functionality/stability as crm_mon we can get rid definitely of both binaries, for that is true.

from ha_cluster_exporter.

okay, let's keep this in the back burner and see how the whole contributing-to-upstream thing goes.

from ha_cluster_exporter.

yep it is definitely something as prio/low or tech-debt but is ok to track

from ha_cluster_exporter.