Acabei de implantar um ambiente físico do Openstack com o mais recente script de instalação estável do Openstack e, em seguida, o piloto automático do Landscape, a instalação de ambas as partes parece ter sido concluída com êxito e agora tenho três servidores fornecendo minha pequena nuvem.
Efetuar login com o nome de usuário e a senha especificados funciona conforme o esperado e a criação de novas instâncias usando o padrão Ubuntu-14.04-server-cloudmg-amd64-disk1 também parece funcionar, a julgar pelo clipe de log:
Cloud-init v. 0.7.5 finished at Tue, 19 Jul 2016 16:56:51 +0000. Datasource DataSourceOpenStack [net,ver=2]. Up 202.90 seconds
No entanto, estou vendo um problema ao selecionar o console:
Eu tentei criar as instâncias da versão 12, assim como ter o mesmo resultado, também cortar novas chaves SSH através do console Horizon e reconstruí-las, mas sem sorte! Não tenho certeza de onde começar, mas tenho a sensação de que será algo relacionado ao KVM e não ser chamado, mas isso é apenas um palpite. Então, qualquer ajuda para resolver isso seria muito apreciada.
Encontrei minha própria resposta - Parece que por algum motivo o script de construção do piloto automático não está configurado para habilitar e configurar o componente do console via "VNC", então o usuário final precisa se conectar ao juju e enviar a configuração para os controladores de nuvem e todos os endpoints da nova.
Não tenho certeza se ele deve ser registrado como um bug ou não, mas certamente isso tirará as pessoas do OpenStack.
Não ativamos o console porque as implicações de segurança disso são horríveis.
O OpenStack Autopilot implantará o OpenStack da melhor e mais segura maneira que sabemos e, infelizmente, isso significa que não há acesso ao console.
Não tenho certeza se entendi o comentário sobre segurança sendo o problema, você está dizendo que o método / protocolo de acesso ao console escolhido pelo OpenStack quando implementado através de uma rede privada e configuração de proxy é tão inseguro que é melhor quebrar o OOB Acesse o recurso totalmente sem "alerta decente para o fato" ou alternativa verdadeira?
Existe um número significativo de nuvens públicas rodando o OpenStack que deve ter superado esse problema de "segurança" e que oferece acesso ao console, então por que isso é fundamentalmente diferente?
Honestamente, esta é a primeira vez que uso uma implementação de software de comando e controle de VM que não tem acesso ao console pronto para o uso AZUE, vCloud, ESX / vCenter, Hyper-v / SCVMM, KVM, Zen / Zenserver. e não tê-lo como ether default ou pelo menos uma opção fácil de selecionar vai afastar um monte de pessoas antes que elas comecem!
Mesmo que haja um retrocesso maciço para habilitar ou oferecer esse recurso por padrão, ter um aviso de isenção grande como parte do Guia publicado ou do sistema operacional Landscape instalado junto com etapas documentadas "bem" para habilitar / contornar isso seria melhor do que um erro inócuo que parece ter sido quebrado durante a instalação?
Isso ainda parece um bug em vez de algo que você escolheria fazer em um produto / pacote com o objetivo de levar as pessoas a buscar o OpenStack.