Quando você tem um agent-state: down
, isso significa que o nó de bootstrap não pode se comunicar com o juju-agent. Como resultado, ele não pode destruir, pois não pode comunicar o próximo conjunto de eventos.
Isso acontece às vezes quando a máquina é destruída fora do juju, então juju acha que ainda está lá, embora a máquina tenha sido removida fisicamente. Você pode confirmar que o opnw02.master ainda está em execução? Em caso afirmativo, tente ssh para ele usando juju ssh 20
ou ssh [email protected]
. Se você puder acessar a máquina, tente reiniciar os juju-agents, que são jujud-machine-#
e jujud-unit-<service>-#
. Então, no seu caso, os seguintes comandos reiniciarão esses serviços
sudo stop jujud-machine-20
sudo stop jujud-unit-quantum-gateway-0
sudo start jujud-machine-20
sudo start jujud-unit-quantum-gateway-0
Neste ponto, o status do juju deve reportar o unit-agent como iniciado novamente. Talvez seja necessário executar juju resolved quantum-gateway/0
algumas vezes, pois parece ter parado durante a execução do meio do gancho. Eventualmente, o serviço deve ir para o curso e ser removido.
Se você não conseguir fazer login na máquina (ele foi destruído fora do juju ou por outros motivos), ele permanecerá no status juju por enquanto. Há trabalho para permitir a "limpeza" de serviços, mas ainda não foi feito (a partir de 1.13.3). Se você quiser implantar o gateway quântico novamente, e o status ainda tiver esse negócio inativo do estado do agente, você poderá implantá-lo com um alias diferente da seguinte forma:
juju deploy quantum-gateway qgateway
Indo adiante, você pode estabelecer relações com ele emitindo juju add-relation nova-compute qgateway