Merge lp:~julian-edwards/maas/better-error-bug-1064212 into lp:~maas-committers/maas/trunk
Proposed by
Julian Edwards
Status: | Merged |
---|---|
Approved by: | Julian Edwards |
Approved revision: | no longer in the source branch. |
Merged at revision: | 1819 |
Proposed branch: | lp:~julian-edwards/maas/better-error-bug-1064212 |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
22 lines (+10/-2) 1 file modified
src/provisioningserver/pxe/config.py (+10/-2) |
To merge this branch: | bzr merge lp:~julian-edwards/maas/better-error-bug-1064212 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Jeroen T. Vermeulen (community) | Approve | ||
Review via email: mp+201883@code.launchpad.net |
Commit message
Expand the error message for missing pxe templates to offer a hint about why they are missing.
Description of the change
This doesn't attempt to fix the underlying problem - that is caused when the purpose "poweroff" is used, for which we have no templates (I don't think you can use pxeconfig to turn a machine off).
Ultimately the problem is caused by PEBKAC, that is someone manually turned on a machine when they should not have. The best course of action is to have a descriptive error message that schools them in the error of their ways.
To post a comment you must log in.
It's good to have a stopgap. Guesswork remains unpleasant, especially when we ask the user to look up information that we have at hand. After all we request information about the node from the API (see pxeconfig() in maasserver/api.py) just before it gets to this point. AFAICS that information could easily be made to include something that tells the tftp server whether the node is supposed to be netbooting right now. If we had that, we could issue a more definite "hands off, this node boots when MAAS says so" message.
The "when MAAS is not expecting that" sounds a little vague, as we're not sure ourselves what is supposed to be happening, or MAAS just felt like dozing off for a bit. Maybe "when it's not supposed to," or "when it's not in a state where MAAS allows it"?
I suppose the error could also happen if the node's state is changed in rapid succession, e.g. if it is allocated and immediately deallocated.