1

I've deployed Ubuntu 14.04 using the installation mode that includes MAAS.

When I commission my nodes, everything looks fine (they go into Ready state). However, I'm unable to use juju bootstrap because it fails.

On the console of the node that is being commissioned I'm getting a series of 500 INTERNAL SERVER ERROR messages (7 of them), followed by several Success messages. Using tcpdump I was able to see that this happens when the node reports back the lshw results (POST /MAAS/metadata//2012-03-01).

In the maas.log file, I am seeing an 'integer out of range' exception. To dig further, I added some logging messages to the commissioningscript.py file and found that the issue happens after parsing the XML, i.e. when the data is saved to the database.

So, since it's a DB error, I went for the postgres log file and found this:

2015-05-28 13:50:39 EDT STATEMENT:
UPDATE "maasserver_node" SET "created" = '2015-05-28 10:03:26.748794', "updated" = '2015-05-28 13:50:39.679737',
"system_id" = 'node-4faee0de-0542-11e5-9313-0050568ea9a6',
"hostname" = 'vmachine02',
"status" = 1,
"owner_id" = NULL,
"distro_series" = '',
"architecture" = 'amd64/generic',
"routers" = ARRAY['18:9c:5d:f6:02:55'::macaddr],
"agent_name" = '',
"zone_id" = 1,
"cpu_count" = 8,
"memory" = 32768,
"storage" = 17592186050704,
"power_type" = 'ipmi',
"power_parameters" = '{"power_driver": "LAN_2_0", "power_address": "10.0.0.12", "power_pass": "ADMIN", "power_user": "ADMIN", "mac_address": "0c:c4:7a:06:ff:fd"}',
"token_id" = NULL,
"error" = 'finished [6/6]',
"netboot" = true,
"nodegroup_id" = 1 WHERE "maasserver_node"."id" = 2
2015-05-28 13:50:55 EDT ERROR:  integer out of range

Looking at that SQL closer, I can see the issue. The 'storage' value is larger than maxint for postgresql (+2147483647).

Going back to the commissioningscript.py file, I can see that XPATH is used to extract the storage total by summing up all of the storage available on the node and dividing by 1024 twice (so it generates a MB number). In my case, to come up with a total storage number of 17592186050704 MB would mean I have somehow invented a very magical storage device in my home lab (quintillions of bytes!). Clearly that's not right.

To get past this issue, I added a test in the commissioningscript.py file after it retrieves the storage number using XPATH: I test and set to 0 if it's too large (meaning unknown):

if storage > 2147483647:
  storage = 0

With this change, things are working better. I think to make the commissioning more robust it would be wise to test for out of range numbers coming out of lshw parsing (for everything, not just storage, but things like memory and cpus). Just in case!

I am not sure how to attach the output I'm getting from lshw to this post, so if a developer would like to see what it looks like, please contact me directly and I'll send it.

0

You must log in to answer this question.

Browse other questions tagged .