Bootstrapping Juju dá “” ERRO não pôde acessar o arquivo '* -provider-state' gomaasapi: erro de volta do servidor: proibido 403. ”

Question

Estamos tentando inicializar o Juju em outra máquina na nuvem MAAS, mas estamos obtendo um "ERRO não foi possível acessar o arquivo *-provider-state gomaasapi: recebemos o erro do servidor: 403 proibido." erro.

Quando executamos juju bootstrap , um arquivo .jenv é criado e esse erro é retornado com o * no '* -provider-state' substituído pelo Nome do Agente Juju do nó MAAS. Quando excluímos o ambiente (excluindo o arquivo .jenv), o mesmo erro é retornado, mas o nome do arquivo apenas é listado como 'provider-state'. O nó não se move para o estado Alocado mesmo que o arquivo .jenv seja criado. Executar qualquer coisa - bootstrap juju, status juju, juju destroy-environment, dá o mesmo erro.

Backstory: Costumava haver um ambiente de Juju bootstrapped existente neste servidor MAAS anteriormente. Tivemos que alterar nossas configurações de rede e não conseguimos que o nó alocado fosse excluído. Então, pensamos que poderíamos desinstalar o juju e começar de novo. Claramente, não funcionou e ainda existem alguns links no nosso servidor. Como nos livramos disso? Nós obtivemos o nó alocado excluído usando o shell do maas, mas esse erro ainda persiste.

Estamos executando o MAAS 12.04 LTS, o Juju 1.16.

    

Answer 1

Primeiro, deletar o arquivo .jenv não destrói o ambiente, apenas torna impossível conectar-se a ele do seu cliente juju. O arquivo .jenv contém todas as informações necessárias para se conectar ao ambiente, incluindo endereços do servidor da API juju, certificados SSL, etc.

Para destruir um ambiente de juju, use: $ juju destroy-environment my-maas-env-name -y

Isso desalocará adequadamente os nós MAAS, excluirá as entradas de armazenamento, incluindo o arquivo provedor-estado .

Além disso, a reinstalação do juju na sua máquina cliente não pode resolver seu problema, porque o ambiente e seus nós alocados ainda estão lá e, para o MAAS, ele aparece enquanto você ainda está usando o ambiente.

Para resolver seu problema específico, eu faria o seguinte:

• Seu ambiente não está mais acessível porque o arquivo .jenv desapareceu e, como é gerado automaticamente, não é possível recuperar o acesso ao ambiente apenas criando um arquivo .jenv vazio.
• Exclua o arquivo .jenv, se ainda estiver lá.
• Faça login como o administrador do MAAS na interface da web do MAAS, vá para "Nós" e, para cada nó alocado, clique no nó e clique em "Parar nó" na página do nó. Isso irá desalocar o nó e trazê-lo de volta para Pronto .
• Usando a MAAS CLI, você pode listar todos os arquivos no armazenamento do ambiente: $ maas my-maas-session files list e excluir o arquivo de armazenamento do provedor: $ maas my-maas-session file delete XXXX-provider-storage (o nome de arquivo exato que você obtém da lista de arquivos, parecerá com c4ba50c2 -268c-4cf4-8be1-c0903982c8a8-provider-state e my-maas-session corresponde à sua sessão de usuário da CLI - pode ser qualquer string, criada com, por exemplo, $ maas login my-session-name http://192.168.50.2/MAAS/ <maas-api-key> - use a mesma chave que você especificou com "maas-oauth "in environments.yaml)
• Bootstrap novamente, uma vez feito, deve funcionar.

Espero que isso ajude,