Skip to content
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

Closed
chu11 opened this issue Jan 23, 2024 · 11 comments
Closed

idea: support busy plugstate #78

chu11 opened this issue Jan 23, 2024 · 11 comments

Comments

@chu11
Copy link
Member

chu11 commented Jan 23, 2024

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
Copy link
Member

garlick commented Jan 23, 2024

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

@chu11
Copy link
Member Author

chu11 commented Jan 23, 2024

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
Copy link
Member Author

chu11 commented Jan 23, 2024

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
Copy link
Member

garlick commented Jan 23, 2024

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

@chu11
Copy link
Member Author

chu11 commented Jan 23, 2024

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
Copy link
Member

garlick commented Jan 23, 2024

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

@chu11
Copy link
Member Author

chu11 commented Jan 23, 2024

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
Copy link
Member

garlick commented Jan 23, 2024

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.

@garlick
Copy link
Member

garlick commented Jan 23, 2024

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

@chu11 chu11 changed the title idea: support more plugstates idea: support busy plugstate Jan 23, 2024
@garlick
Copy link
Member

garlick commented Jan 25, 2024

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...

@garlick garlick closed this as completed Jan 25, 2024
@chu11
Copy link
Member Author

chu11 commented Jan 26, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants