Bug 2477435

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.