idea: support busy plugstate

[chu11]

Per discussion in #68, redfish supports the idea of a "poweringOff" and "poweringOn" state, i.e. in the process of going off/on.

So there are "other states" than "off" and "on" in power control, it may be interesting to allow those to be output as well i.e.

$ pm -q
on: ...
off: ...
poweringOff: ...
poweringOn: ...
unknown: ...

[garlick]

Or maybe just a generic "busy" state so you know something's in progress?

[chu11]

Or maybe just a generic "busy" state so you know something's in progress?

Ahh I like that idea. That can be a catch all for "something we're aware of ... it's not really an error", vs unknown which is indicative of an error or problem.

[chu11]

hmmm on that idea would an error state be worthwhile? to categorize known errors and "unknown" is for something we don't know about? i.e. error could be authentication issues or DNS can't lookup issues, etc.

[garlick]

I think "unknown" always means there was an error doesn't it? (I am actually not 100% sure)

[chu11]

I think "unknown" always means there was an error doesn't it? (I am actually not 100% sure)

Right now i think unknown means "a state we don't know about". So my thinking above is error is a collection of known errors that require user to re-configure or something and unknown means actually unknown.

[garlick]

I think I need an example of unknown that is not an error to be convinced :-)

[chu11]

I think I need an example of unknown that is not an error to be convinced :-)

fair enough, what if it were instead:

$ pm -q
on: ...
off: ...
config error: ...
unknown: ...

which gives user a clue what's wrong? I guess that was what I was more thinking of.

[garlick]

If we could address

• 76

• 77

then it seems like we would not need states for config errors and such. Errors and warnings would (somehow) get displayed on the client's stderr.

[garlick]

If you're in agreement then I would change the title of this issue to idea: support busy plugstate.

[garlick]

I'm going to close this because I don't think it's possible. If a command is in progress, then a status query would queue up behind the in-progress command and not be responded to until nothing is busy. Reopen if I'm missing something...

[chu11]

I'm going to close this because I don't think it's possible. If a command is in progress, then a status query would queue up behind the in-progress command and not be responded to until nothing is busy. Reopen if I'm missing something...

Just going to add some context for anyone reading in future

if --nowait (#68) is not implemented, then correct, this generally would be impossible b/c generally we always wait for a command to complete. Would be possible if errors or node stuck scenarios.

If --nowait is implemented where the client disconnects from powermand, would be impossible b/c query can't connect to in-progress command.

if --nowait were implemented via a new scriptlet (e.g. script on_nowait) then could be possible.