Como restaurar o MAAS 1.5, LTS 14.04

Question

Eu tenho experimentado com o MAAS, seguindo link , usando 14.04. Eu devo ter feito algo errado, já que não sou capaz de inicializar o ambiente do MAAS. Aqui está a parte relevante do meu environment.yaml:    maas:         tipo: maas

    # maas-server specifies the location of the MAAS server. It must
    # specify the base path.
    #
    maas-server: 'http://10.0.0.10/MAAS/'

    # maas-oauth holds the OAuth credentials from MAAS.
    #
    maas-oauth: 'xxxxx...xxxxxx'
    admin-secret: '123456'
    default-series: 'trusty'

O nó de destino está no estado pronto, conforme indicado no MAAS web gui, e eu posso ssh para ele, ssh [email protected]. No entanto, o bootstrap fica preso durante o login no nó de destino:

2014-05-15 16:36:43 INFO juju.cmd supercommand.go:297 running juju-1.18.1-trusty-amd64 [gc]
2014-05-15 16:36:43 WARNING juju.cmd.juju common.go:40 ignoring environments.yaml: using bootstrap config in file "/home/navesta/.juju/environments/maas.jenv"
2014-05-15 16:36:43 DEBUG juju.environs open.go:86 ConfigForName found bootstrap config map[string]interface {}{"bootstrap-addresses-delay":10, "ca-cert":"-----BEGIN CERTIFICATE-----\nMIICWTCCAcSgAwIBAgIBADALBgkqhkiG9w0BAQUwQjENMAsGA1UEChMEanVqdTEx\nMC8GA1UEAwwoanVqdS1nZW5lcmF0ZWQgQ0EgZm9yIGVudmlyb25tZW50ICJtYWF
...
2014-05-15 16:36:49 DEBUG juju.provider.maas environ.go:311 maas user data; 1315 bytes
2014-05-15 16:36:50 DEBUG juju.provider.maas environ.go:317 started instance "/MAAS/api/1.0/nodes/node-2ce27bec-dba9-11e3-940c-525400bba9bf/"
 - /MAAS/api/1.0/nodes/node-2ce27bec-dba9-11e3-940c-525400bba9bf/
2014-05-15 16:36:50 DEBUG juju.environs.bootstrap state.go:41 putting "provider-state" to bootstrap storage *maas.maasStorage
Waiting for address
Attempting to connect to hbby7.maas:22
Attempting to connect to 10.0.0.31:22
2014-05-15 16:36:50 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/navesta/.juju/ssh/juju_id_rsa -i /home/navesta/.ssh/id_rsa [email protected] /bin/bash
2014-05-15 16:36:50 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/navesta/.juju/ssh/juju_id_rsa -i /home/navesta/.ssh/id_rsa [email protected] /bin/bash
2014-05-15 16:36:55 DEBUG juju.utils.ssh ssh_openssh.go:122 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i /home/navesta/.juju/ssh/juju_id_rsa -i /home/navesta/.ssh/id_rsa [email protected] /bin/bash

Outro sintoma do meu problema é que, enquanto meu nó de destino está no estado pronto, ele será encerrado na reinicialização. Para evitar esse problema, tenho que colocá-lo no modo Alocado e reiniciá-lo. Eu tentei remover, re-comissionando e destruindo o ambiente de massa, sem sucesso. (Também seguido, Redefinir o MAAS depois de perder a configuração do Juju? , mas as APIs parecem ter mudado.) Qualquer sugestão ou pensamento é apreciado. Felicidades,

    

Answer 1

Portanto, você deve ter seus nós no estado Pronto antes de tentar usar o Juju com eles. Certifique-se de que todas as suas VMs estejam configuradas para inicialização de rede e estejam desativadas. O MAAS irá ligá-los quando necessário (ou seja, quando a Juju quiser implantar algo para eles).

Um problema que você pode estar encontrando é que Juju pode tempo limite tentando SSH para os nós. Você pode configurar o tamanho do tempo limite em seu arquivo environments.yaml. Consulte as notas de lançamento do Juju 1.18.0 para obter mais detalhes.

    

Answer 2

juju juju.utils.ssh ssh_openssh.go ignora .ssh / config e $ ssh < ... > / bin / bash precisa de uma opção extra -o "RequestTTY yes"

Parece que no upstream existe um double -t para "resolver" o problema, mas minha sugestão seria usar o .ssh / config