MAAS на Ubuntu 14.04 ошибка ввода в эксплуатацию (lshw не перехвачено)
Я развернул Ubuntu 14.04, используя режим установки, включающий MAAS.
Когда я запускаю свои узлы, все выглядит нормально (они переходят в состояние готовности). Тем не менее, я не могу использовать juju bootstrap, потому что он не работает.
На консоли узла, который вводится в эксплуатацию, я получаю серию 500 INTERNAL SERVER ERROR сообщений (7 из них), за которыми следуют несколько сообщений об успехе. Используя tcpdump, я смог убедиться, что это происходит, когда узел сообщает результаты lshw (POST /MAAS/metadata//2012-03-01).
В файле maas.log я вижу исключение «целое число вне диапазона». Чтобы продолжить, я добавил несколько сообщений в файл commissioningscript.py и обнаружил, что проблема возникает после анализа XML, то есть, когда данные сохраняются в базе данных.
Итак, так как это ошибка БД, я нашел файл журнала postgres и обнаружил следующее:
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
При более внимательном рассмотрении этого SQL я вижу проблему. Значение 'storage' больше, чем maxint для postgresql (+2147483647).
Возвращаясь к файлу commissioningscript.py, я вижу, что XPATH используется для извлечения общего объема хранилища путем суммирования всего хранилища, доступного на узле, и деления на 1024 дважды (таким образом, он генерирует число МБ). В моем случае, общее количество хранилищ 17592186050704 МБ означало бы, что я как-то изобрел очень магическое устройство хранения в моей домашней лаборатории (квинтиллионы байтов!). Очевидно, что это не так.
Чтобы обойти эту проблему, я добавил тест в файл commissioningscript.py после того, как он извлекает номер хранилища, используя XPATH: я проверяю и устанавливаю 0, если он слишком большой (имеется в виду неизвестный):
if storage > 2147483647:
storage = 0
С этим изменением дела идут лучше. Я думаю, чтобы сделать ввод в эксплуатацию более надежным, было бы целесообразно проверить наличие номеров вне диапазона, возникающих при разборе lshw (для всего, не только для хранения, но и для таких вещей, как память и процессор). На всякий случай!
Я не уверен, как прикрепить вывод, который я получаю от lshw, к этому сообщению, поэтому, если разработчик захочет посмотреть, как он выглядит, свяжитесь со мной напрямую, и я отправь.