-
Notifications
You must be signed in to change notification settings - Fork 19
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
idea: support busy plugstate #78
Comments
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. |
hmmm on that idea would an |
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 |
I think I need an example of |
fair enough, what if it were instead:
which gives user a clue what's wrong? I guess that was what I was more thinking of. |
If we could address
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. |
If you're in agreement then I would change the title of this issue to |
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 If if |
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.
The text was updated successfully, but these errors were encountered: