-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: consolidate empty lines in flux resource list's default format #6275
Comments
To explain a little more simply, I propose something where in the first situation you would end up with this output:
|
Note that we don't currently have a way to expand a field to make room for a larger list of queues, so at this point the output would be more like:
Which is probably unhelpful |
I don't suppose it's reasonable to increase the default format's {queue} field to length 20? I have no feel for how common overlapping queues are outside if LLNL. |
Another approach might be to develop a format specifier or other indicator that sets the width of a field to the minimum width that would not result in the field being truncated on any line. We do already have the Then we could look into combining the empty sets into one line. |
This is a substantially better idea! |
Ok, now that #6284 has been merged, we can safely change the behavior of The result goes from this:
to:
I'm not sure if this is confusing or not. Maybe @kkier's initial suggestion (offline) to suppress "empty" lines by default would be better? (This is what Happy to go either way here. |
Looking back, it is a bit confusing that non-empty sets that overlap are combined (e.g. all,debug) and not the empty set. Though admittedly an empty set is a special case since it has no nodes, the nodelist for all queues matches. Perhaps it would be good to present empty sets on one line, regardless of whether they are displayed by default or not. |
The current/new-in-.65 behavior is to output a full line for each empty queue in
flux resource list
like so:I'm wondering if it might be cleaner to, in the case of lines with 0 nodes associated, use
state
as a primary indicator and combine the queue list like we do with overlapping queues, so you'd end up with something like:Immediate problem I see is that this causes some conceptual overlap between "the first line above indicates these queues have 0 nodes in this state" and "the first line above indicates that there are 0 nodes in this state who that are also members of both of these queues." I don't think of that as being confusing offhand, but I can see how that might not be universal.
To put it another way, in the example above does this line mean "there are no nodes in queues
bar
orquux
that are free," or does it mean "there are no nodes in both queuesbar
andquux
that are free, but there may be nodes in either of them individually free."Reading this back, I'm not sure if it makes 100% sense...
The text was updated successfully, but these errors were encountered: