O ambiente JUJU e ERROR não possui chave de acesso ou chave secreta

Question

seguindo o guia oficial:

• link

e considerei que eu criei a chave ssh (adicionada à interface do usuário do MAAS) e a chave da API, meu arquivo environments.yaml apresenta desta forma:

environments:
  maas:
    type: maas
    maas-server: 'http://x.x.x.x/MAAS/'
    maas-oauth: 'NDPA86PsEzS7bFynSy:vqJLkyHUJbvYzbtY5Q:sXXXXXXXXXXXXXXXXXXXXXX
    admin-secret: 'nothing'
    default-series: precise
    authorized-keys-path: ~/.ssh/id_rsa.pub # or any file you want.

quando tento executar o comando:

juju bootstrap

receba o seguinte erro:

ERROR environment has no access-key or secret-key

Alguém pode me explicar onde está errado?

• MAAS e JUJU são instalados usando seu ppa stable em um servidor Ubuntu 12.04.3
• Eu já inscrevi duas máquinas no meu Maas e elas estão em status de comissionamento
• No arquivo environments.yaml, a linha "default" tem como valor "maas"

Answer 1

Quando os nós no MaaS estão no estado de comissionamento, eles não estão disponíveis para serem usados pelo Juju. Quando os nós estiverem prontos para alocação, eles serão mostrados no MaaS como o estado Ready .

Quando você faz o bootstrap usando o Juju, ele cria um nó que enfileira os futuros comandos deploy e relation setting para serem executados no momento correto durante a instalação dos vários serviços.

O erro gomaasapi: got error back from server: 409 CONFLICT é um erro genérico que significa que o Maas encontrou e errou ao tentar atender sua solicitação. No seu caso, como todas as suas máquinas estão em estado de comissionamento e não estão prontas, o MaaS não possui nós que o Juju possa usar para configurar a máquina de bootstrap. Por causa disso, você recebe o erro 409 CONFLICT .

Quando os nós estão no estado commissioning , eles devem ser inicializados, executando uma imagem do servidor MaaS que os prepara para uso. Você pode querer verificar se os nós que estão supostamente comissionando são inicializados e não estão presos em algum prompt de inicialização ou desligado. Se eles estiverem em execução, tente conectar um monitor a eles e veja o que você pode ver.

Se eles não estiverem em execução, verifique se você tem a configuração de energia definida no MaaS correta - o MaaS pode não sinalizar as máquinas para inicializar (usando IPMI, WOL, etc.) e, portanto, a imagem de comissionamento nunca é inicializado e executado e os nós estão presos no estado de comissionamento sem intervenção humana. (Se este for o caso, você pode passar por isso manualmente (como em fisicamente se as máquinas são físicas, ou dizendo VirtualBox para iniciar a VM, se é isso que você está usando) alimentando os nós que estão presos no comissionamento estado.)

Se você estiver usando máquinas virtuais para testar o MaaS, avise-me e atualizarei minha resposta - há algumas peculiaridades para testar o MaaS com máquinas virtuais.

    

Answer 2

A partir do erro especificado, posso supor que você está usando o juju-core e tentando usar o provedor do EC2 de alguma forma. Tem certeza de que você não tem outros ambientes em seus ambientes.YAML? Você precisará especificar default: maas no nível superior de seu environments.yaml ou, como alternativa, usar juju switch maas na linha de comando. Será útil publicar seus ambientes completos.yaml, bem como mais contexto a partir da saída do comando (qual comando você executou?), Passando --show-log como um argumento.

    

Answer 3

Richard, se você ainda estiver tentando testar o MAAS em um ambiente virtual, posso ajudá-lo. Eu tenho MAAS executando com sucesso em uma máquina virtual interagindo com outros dois grandes VM Servers que possuem suas próprias máquinas virtuais. No meu ambiente, o servidor MAAS controla e inicializa as VMs em meus VM Servers. Eu tenho conseguido implantar com sucesso o Wordpress e vários outros pequenos aplicativos em meus VM Servers (Virt-Manager, QEMU e KVM). Um dos principais conselhos é usar o MAAS 13.10; o código é muito estável e há várias correções e recursos importantes em 12.04 LTS. Descobri que usando o "padrão: maas" no início dos meus ambientes.YAML fez com que ele falhasse, aconselho usar a opção -e com seu comando de inicialização, se você estiver implantando em uma nuvem (por exemplo, Azure, AWS, HP Cloud).

Você precisará editar /etc/maas/pserv.yaml para fazer o boot do PXE funcionar. Na seção sobre TFTP, remova o comentário da linha que designa a "raiz", a linha que designa a "porta" e a linha que define o gerador.

O "Fast Installer" não funcionou com meus VM Servers, portanto, se você estiver virtualizado, talvez dê uma falha a esse recurso na primeira instância.

Os "Charms" têm suas próprias definições embutidas ("restrições") nas CPUs e na memória necessárias para executá-las. Não está claro na documentação, mas descobri que eu tenho o erro genérico 409 CONFLICT tentando implantar o Wordpress e o mysql em qualquer coisa com menos de 2048MB de RAM, acho que também tive que colocar 2 CPUs cada nas minhas VMs. Pode ser diferente para você, isso é exatamente o que eu encontrei.

    

Answer 4

Consegui que funcionasse executando o comando juju switch local .

    

Answer 5

Ele solicita credenciais dos servidores em nuvem. Se você gosta de testar em seu uso local, siga o comando

sudo apt-get install juju-local