I just realized that pcs appears to pass constraint options along without restricting them to known names, so nothing special needs to be done to support "influence".

However Marketa Smazova in QE raised the question of whether "critical" should change how a colocation constraint is displayed. In other words, if someone configures a colocation with influence=false, then "pcs constraint colocation show" will display "(influence:false)", but if someone sets critical=false on the resource instead, "pcs constraint colocation show" will not give any indication that influence has been disabled.

I don't have a preference on how that should be handled, but it's a good question to think about.

As Ken mentioned in comment 1, setting 'influence' constraint option and 'critical' resource meta-attribute is already possible with pcs. Displaying '(influence:false)' in colocation constraints works as well.

Displaying '(critical:false)' in collocation constraints next to resources is a different story, though. The meta-attribute can be either set in a resource, in its parent (clones, groups) or in resource defaults. Resource defaults support rules, and resource meta-attributes can also use them, even though pcs is not capable of configuring them yet. In these cases, displaying simply '(critical:false)' would be misleading, as it would not be true all the time, and displaying all the details with rules would be confusing. Displaying an applied configuration is currently not possible either: 1) pcs would have to reimplement pacemaker's logic to determine the applied configuration, 2) 'pcs constraint colocation config' displays configuration and not currently applied values (that would have to be another command), so we don't want to mix those two.

Therefore, I'm closing this as wontfix. If this issue becomes serious, feel free to reopen the bz.