Fedora Account System
Red Hat Associate
Red Hat Customer
When resources are in an order set: $ sudo pcs constraint --output-format=cmd pcs -- constraint colocation \ set nfs_data_infodir nfs_data_software nfs_data_animaletti nfs_data_multimedia nfs_ipv4 nfs_ipv6 nfs_server nfs_export_root nfs_export_software nfs_export_multimedia nfs_export_animaletti \ set nfs_data_drbd-clone role=Promoted \ setoptions id=colocation_set-nfs_server score=INFINITY; pcs -- constraint order \ set nfs_data_drbd-clone action=promote \ set nfs_data_infodir nfs_data_software nfs_data_animaletti nfs_data_multimedia nfs_ipv4 nfs_ipv6 nfs_server nfs_export_root nfs_export_software nfs_export_multimedia nfs_export_animaletti action=start \ setoptions id=order_set-nfs_server ... and you call pcs resource relations to see a tree-structure representation of those sets, they are printed out in the correct order at the beginning of the command but the tree fails to render. Instead, a sorted list is presented. Few examples below: $ sudo pcs resource relations nfs_data_software nfs_data_software `- order set | set nfs_data_drbd-clone (action=promote) | set nfs_data_infodir nfs_data_software nfs_data_animaletti nfs_data_multimedia nfs_ipv4 nfs_ipv6 nfs_server nfs_export_root nfs_export_software nfs_export_multimedia nfs_export_animaletti (action=start) |- nfs_data_animaletti |- nfs_data_drbd-clone | `- inner resource(s) | `- nfs_data_drbd |- nfs_data_infodir |- nfs_data_multimedia |- nfs_export_animaletti |- nfs_export_multimedia |- nfs_export_root |- nfs_export_software |- nfs_ipv4 |- nfs_ipv6 `- nfs_server $ sudo pcs resource relations nfs_ipv4 nfs_ipv4 `- order set | set nfs_data_drbd-clone (action=promote) | set nfs_data_infodir nfs_data_software nfs_data_animaletti nfs_data_multimedia nfs_ipv4 nfs_ipv6 nfs_server nfs_export_root nfs_export_software nfs_export_multimedia nfs_export_animaletti (action=start) |- nfs_data_animaletti |- nfs_data_drbd-clone | `- inner resource(s) | `- nfs_data_drbd |- nfs_data_infodir |- nfs_data_multimedia |- nfs_data_software |- nfs_export_animaletti |- nfs_export_multimedia |- nfs_export_root |- nfs_export_software |- nfs_ipv6 `- nfs_server Reproducible: Always Steps to Reproduce: 1. Create a resource order constraint set 2. Call pcs resource relations to see a tree of that set Actual Results: You get an ordered list (well, I guess I get kind of tree but still it's ordered incorrectly) Expected Results: You get a tree representation in which resources are ordered as they are in the config and dependencies are ordered like a tree
Hi @luca.cavana, To make sure I fully understand your expected results, I put together a quick example based on your report. Let's assume we have the following setup: # RESOURCES=(A1 A2 A3 B1 B2 B3 C1 C2 C3) # for r in ${RESOURCES[*]}; do pcs resource create $r ocf:pacemaker:Dummy; done # pcs constraint order set A1 A2 A3 set B1 B2 B3 sequential=false set C1 C2 C3 The current behavior for resource A1 outputs this tree: # pcs resource relations A1 A1 `- order set | set A1 A2 A3 | set B1 B2 B3 (sequential=false) | set C1 C2 C3 |- A2 |- A3 |- B1 |- B2 |- B3 |- C1 |- C2 `- C3 Is the mock-up below closer to what you are expecting to see? In this mock-up, I tried to visualize a tree that explicitly shows the sequential order both between the sets and within the sets themselves: # pcs resource relations A1 (Mock-up) A1 `- order set | set A1 A2 A3 | set B1 B2 B3 (sequential=false) | set C1 C2 C3 `- resource set `- order in set | | start A1 then start A2 | `- A2 | `- order in set | | start A2 then start A3 | `- A3 `- resource set |- B1 |- B2 |- B3 `- resource set |- C1 `- order in set | start C1 then start C2 `- C2 `- order in set | start C2 then start C3 `- C3 I wanted to provide some context on why the current tree is structured the way it is. The top section of the output already displays the exact order of the resource sets and their internal ordering rules: `- order set | set A1 A2 A3 | set B1 B2 B3 (sequential=false) | set C1 C2 C3 The second part of the tree is intentionally designed to highlight external or secondary relationships (such as ORDER_SET, ORDER, INNER_RESOURCES, and OUTER_RESOURCE) rather than re-stating the internal set order. Because there are no additional relations for these resources in this example, they are simply listed alphabetically: |- A2 |- A3 ... `- C3 Additionally, because a set can have sequential=false (where internal resource order doesn't matter), keeping a strict sequential tree view isn't always applicable. Let me know if the current behavior is causing specific usability issues for you, or if a different visualization like the mock-up above would better fit your workflow!
Hi @mlisik, > Is the mock-up below closer to what you are expecting to see? Yes, absolutely. The man page and inline help of pcs both states "Display relations of a resource specified by its id with other resources in a tree structure. Supported types of resource relations are: ordering constraints, ordering set constraints, relations defined by resource hierarchy (clones, groups, bundles)." ... instead what you actually get is very close to a display of what ordering sets the resource is in, displayed verbatim as written in the configuration (and that information can be obtained by other means). It does neither iterates inside the cloned resources when these are in the order set in the first part of the output; you just see it iterating inside the cloned resources when these are listed alphabetically in the second part of the output. I've edited your mock-up here making C1 a clone resource. # pcs resource relations A1 (Mock-up) A1 `- order set | set A1 A2 A3 | set B1 B2 B3 (sequential=false) | set C1-clone C2 C3 `- resource set `- order in set | | start A1 then start A2 | `- A2 | `- order in set | | start A2 then start A3 | `- A3 `- resource set |- B1 |- B2 |- B3 `- resource set |- C1-clone ` - inner resource(s) `- C1 `- order in set | start C1-clone then start C2 `- C2 `- order in set | start C2 then start C3 `- C3 ... the only thing with clones is that you can have different types of them (and my example covers a simple promotable clone with 1 instance) but as it's already rendered in the second part of the output I guess the visualization of the different kind of clones is already taken care of. Your mock-up shows very clearly how things are going to play out in that ordering set (with a nice addition of having it also iterates inside clones, if present in the cluster). > Let me know if the current behavior is causing specific usability issues for you, or if a different visualization like the mock-up above would better fit your workflow! It's just unexpected output based on the description of it made in the manual page and inline help. In my eyes, the fix can be either explaining it better (as you already did) in the software or implementing the visualization of your mock-up. The latter I think to be the most useful of the two.