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
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.
Revision history for this message
Jeroen T. Vermeulen (jtv) wrote :

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.

review: Approve
Revision history for this message
Julian Edwards (julian-edwards) wrote :

On 16/01/14 17:51, Jeroen T. Vermeulen wrote:
> Review: Approve
>
> 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.

True, but "purpose" is just as good here.

> 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'll re-word 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.

Possibly yes. But unlikely, I hope.

Thanks for the review!

Revision history for this message
MAAS Lander (maas-lander) wrote :
Download full text (17.7 KiB)

The attempt to merge lp:~julian-edwards/maas/better-error-bug-1064212 into lp:maas failed. Below is the output from the failed tests.

Ign http://security.ubuntu.com saucy-security InRelease
Get:1 http://security.ubuntu.com saucy-security Release.gpg [933 B]
Ign http://nova.clouds.archive.ubuntu.com saucy InRelease
Get:2 http://security.ubuntu.com saucy-security Release [49.6 kB]
Ign http://nova.clouds.archive.ubuntu.com saucy-updates InRelease
Hit http://nova.clouds.archive.ubuntu.com saucy Release.gpg
Get:3 http://nova.clouds.archive.ubuntu.com saucy-updates Release.gpg [933 B]
Hit http://nova.clouds.archive.ubuntu.com saucy Release
Get:4 http://nova.clouds.archive.ubuntu.com saucy-updates Release [49.6 kB]
Get:5 http://security.ubuntu.com saucy-security/main Sources [23.9 kB]
Hit http://nova.clouds.archive.ubuntu.com saucy/main Sources
Get:6 http://security.ubuntu.com saucy-security/universe Sources [7,454 B]
Hit http://nova.clouds.archive.ubuntu.com saucy/universe Sources
Get:7 http://security.ubuntu.com saucy-security/main amd64 Packages [68.8 kB]
Hit http://nova.clouds.archive.ubuntu.com saucy/main amd64 Packages
Hit http://nova.clouds.archive.ubuntu.com saucy/universe amd64 Packages
Hit http://nova.clouds.archive.ubuntu.com saucy/main Translation-en
Hit http://nova.clouds.archive.ubuntu.com saucy/universe Translation-en
Get:8 http://security.ubuntu.com saucy-security/universe amd64 Packages [26.4 kB]
Hit http://security.ubuntu.com saucy-security/main Translation-en
Hit http://security.ubuntu.com saucy-security/universe Translation-en
Ign http://security.ubuntu.com saucy-security/main Translation-en_US
Get:9 http://nova.clouds.archive.ubuntu.com saucy-updates/main Sources [62.8 kB]
Get:10 http://nova.clouds.archive.ubuntu.com saucy-updates/universe Sources [43.0 kB]
Get:11 http://nova.clouds.archive.ubuntu.com saucy-updates/main amd64 Packages [184 kB]
Ign http://security.ubuntu.com saucy-security/universe Translation-en_US
Get:12 http://nova.clouds.archive.ubuntu.com saucy-updates/universe amd64 Packages [126 kB]
Hit http://nova.clouds.archive.ubuntu.com saucy-updates/main Translation-en
Hit http://nova.clouds.archive.ubuntu.com saucy-updates/universe Translation-en
Ign http://nova.clouds.archive.ubuntu.com saucy/main Translation-en_US
Ign http://nova.clouds.archive.ubuntu.com saucy/universe Translation-en_US
Ign http://nova.clouds.archive.ubuntu.com saucy-updates/main Translation-en_US
Ign http://nova.clouds.archive.ubuntu.com saucy-updates/universe Translation-en_US
Fetched 643 kB in 0s (2,240 kB/s)
Reading package lists...
sudo DEBIAN_FRONTEND=noninteractive apt-get -y \
     --no-install-recommends install apache2 avahi-daemon avahi-utils bind9 bind9utils build-essential curl daemontools distro-info dnsutils firefox freeipmi-tools ipython isc-dhcp-common libjs-raphael libjs-yui3-full libjs-yui3-min libpq-dev make postgresql-9.1 python-amqplib python-avahi python-bzrlib python-celery python-convoy python-cssselect python-curtin python-dbus python-dev python-distro-info python-django python-django-piston python-django-south python-djorm-ext-pgarray python-docutils python-formencode python-httplib2 python-jinja2 python-lockfile python...

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'src/provisioningserver/pxe/config.py'
2--- src/provisioningserver/pxe/config.py 2013-10-07 09:12:40 +0000
3+++ src/provisioningserver/pxe/config.py 2014-01-16 09:35:24 +0000
4@@ -71,8 +71,16 @@
5 if error.errno != ENOENT:
6 raise
7 else:
8- raise AssertionError(
9- "No PXE template found in %r!" % pxe_templates_dir)
10+ error = (
11+ "No PXE template found in %r for:\n"
12+ " Purpose: %r, Arch: %r, Subarch: %r\n"
13+ "This can happen if you manually power up a node when its "
14+ "state is not one that allows it. Is the node in the 'Declared' "
15+ "or 'Ready' states? It needs to be Enlisting, Commissioning or "
16+ "Allocated."
17+ % (pxe_templates_dir, purpose, arch, subarch))
18+
19+ raise AssertionError(error)
20
21
22 def render_pxe_config(kernel_params, **extra):