Eu implantei o Ubuntu 14.04 usando o modo de instalação que inclui o MAAS.
Quando eu encomendo meus nós, tudo parece bem (eles entram no estado Pronto). No entanto, não consigo usar o bootstrap de juju porque ele falha.
No console do nó que está sendo comissionado, recebo uma série de 500 INTERNAL SERVER ERROR messages (7 delas), seguidas por várias mensagens Success. Usando o tcpdump eu pude ver que isso acontece quando o nó relata os resultados do lshw (POST / MAAS / metadata // 2012-03-01).
No arquivo maas.log, estou vendo uma exceção 'inteiro fora do intervalo'. Para cavar ainda mais, adicionei algumas mensagens de log ao arquivo commissioningscript.py e descobri que o problema ocorre após a análise do XML, ou seja, quando os dados são salvos no banco de dados.
Então, como é um erro de banco de dados, eu fui para o arquivo de log postgres e encontrei o seguinte:
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
Olhando para o SQL mais perto, posso ver o problema. O valor de 'armazenamento' é maior que maxint para postgresql (+2147483647).
Voltando ao arquivo commissioningscript.py , posso ver que o XPATH é usado para extrair o total de armazenamento somando todo o armazenamento disponível no nó e dividindo por 1024 duas vezes (portanto, ele gera um número MB). No meu caso, para chegar a um número total de armazenamento de 17592186050704 MB significaria que de alguma forma eu inventei um dispositivo de armazenamento muito mágico em meu laboratório em casa (quintilhões de bytes!). Claramente isso não está certo.
Para superar esse problema, adicionei um teste no arquivo commissioningscript.py depois que ele recupera o número de armazenamento usando o XPATH: Eu testo e defino como 0 se for muito grande (ou seja, desconhecido):
if storage > 2147483647:
storage = 0
Com essa mudança, as coisas estão funcionando melhor. Eu acho que para tornar o comissionamento mais robusto, seria sensato testar números fora do intervalo que saiam da análise de lshw (para tudo, não apenas armazenamento, mas coisas como memória e CPU). Apenas no caso!
Não sei como anexar a saída que estou recebendo do lshw para este post, portanto, se um desenvolvedor quiser ver como é, entre em contato diretamente e eu o enviarei.