idea: output progress indicator waiting for command to complete

[chu11]

As mentioned in #68, several tools wait until a on/off has completed. and some can take quite awhile.

To give the user notion that this is happening instead of the command hanging, it'd be nice if there was option to have some sort of "waiting" message, or perhaps a spinner or something similar.

[garlick]

That's a good idea...some sort of progress indicator if the command takes longer than a couple of seconds maybe.

Without remembering how the internals work very well: I wonder if powerman could treat any received text from a device as "progress" and somehow indicate that to the client? Then something like redfishpower that is engaging in timed polling could output something on each poll?

[chu11]

Without remembering how the internals work very well: I wonder if powerman could treat any received text from a device as "progress" and somehow indicate that to the client? Then something like redfishpower that is engaging in timed polling could output something on each poll?

Yeah, that's exactly what I was thinking like

redfishpower> on foo1
foo1: waitingOn
foo1: waitingOn
foo1: waitingOn
foo1: waitingOn
foo1: On

and we could do in ipmipower too.

and "progress indicator" is a much better phrase than what I have in the title, will update :-)

[chu11]

brainstorming with @adambertsch, progress bar probably preferred, especially at scale, like

$ pm --off foo[1-1000]

[garlick]

I was kind of vaguely thinking we'd allow stderr to come back from the coprocess to powermand and then use that to drive a little propeller or something in the client? Maybe we could do that and also tag each message with a numerical level and let various levels of --verbose decide what, if anything, is emitted on the client's stderr?

Maybe for a progress bar (in addition to propeller?) we could have powerman update it each time a device completes the requested operations. Since those are in parallel, that might tend to be all at once, but if something's wrong maybe not...

So you get

$ pm --off foo[1-10000]
/  [==================.........................]

or

$ pm -off foo[1-1000]
redfishpower: foo4 timed out after 60s
/  [=================..........................]

[chu11]

Since those are in parallel, that might tend to be all at once, but if something's wrong maybe not...

Oh that's a good point, it is often in parallel so it'd all finish around the same time.

My first thought would be "X/1000" instead, but I guess it'd be the same thing as the progress bar. The real point is if it gets to "997/1000" done, and it stops/hangs, you know there's 3/1000 hanging/not configured right/something, and the error messags would give details on it.

[garlick]

One problem: If there are say 10 redfishpower instances each with 100 nodes, then I think a failure to turn off one node will cause the expect script for all 100 nodes to fail. Thus if powerman is reporting what it knows, it will say 900 of 1000 succeeded when actually 999 of 1000 did.

Edit: maybe that's an argument to leave the numbers out of it and go with the progress bar which everybody expects to lie anyway :-)

Edit: on the other hand, if we fix #79 this is not a problem.

[chu11]

@JohnWestlund had a neat idea, although it's probably a bigger ask.. ctrl+C can tell you which nodes you're still waiting on, sorta like pdsh.

[garlick]

Agreed that would be neat. I'm not sure offhand how hard it would be. Pdsh is easy because the work is happening right there in the process that got the signal, but in powerman's case it'd have to be an additional query from client to server.