use crm_mon instead parsing cib with cibadmin for constraint metric

[MalloZup]

Parsing CIB with cibadmin is something we should remove and use more "conventional" tools like crm_mon.

Also right now we should use just crm_mon and improve it upstream to support the needed data.

In past we parsed the cib with cibadmin as workaround but the cleanest solution would be to implement the metric with crm_mon

see the only one metric we build with that:

ha_cluster_exporter/collector/pacemaker/pacemaker.go

Line 210 in 0af48bf

for _, constraint := range CIB.Configuration.Constraints.RscLocations {

[stefanotorresi]

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?

[MalloZup]

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)

[stefanotorresi]

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!

[MalloZup]

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.

[stefanotorresi]

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

[MalloZup]

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