Preciso colocar metadados de imagem em um bucket privado?

Question

Estou experimentando usar o Juju (16.6) para implantar serviços em nossa nuvem privada Openstack e notei alguns problemas.

Ao inicializar um novo ambiente, o Juju aparentemente deseja procurar no bucket do ambiente por metadados de imagem. Eu criei um bucket "público", usando Swift para o armazenamento de objetos, e o preenchai com os metadados de imagem em caminhos de objeto "streams / v1 / *" - no entanto, quando o bootstrapping juju falha a menos que os meta-dados estejam no balde privado do meio ambiente. Isso é normal? E há uma solução na configuração do ambiente para corrigir esse problema?

Meu ambiente é o seguinte (menos chaves ssh):

access-key: ""
admin-secret: ""
agent-version: 1.16.6
api-port: 17070
auth-mode: userpass
auth-url: http://173.23.181.5:5000/v2.0
authorized-keys: 'ssh-rsa '...
...
ca-private-key: ""
control-bucket: juju-bucket
default-image-id: ""
default-instance-type: ""
default-series: precise
development: false
firewall-mode: instance
image-metadata-url: ""
logging-config: <root>=INFO
name: openstack-ws
password: xxxxxxxxxx
public-bucket: juju-dist
public-bucket-url: ""
region: regionOne
secret-key: ""
ssl-hostname-verification: true
state-port: 37017
tenant-name: WebServices
tools-url: ""
type: openstack
use-floating-ip: true
username: xxxxx

Depois de conseguir o ambiente para o bootstrap, eu vou tentar abrir um serviço. No meu caso, estou usando o charme do Hadoop. Quando eu implantar o mestre do hadoop ( juju deploy hadoop hadoop-master ), a instância falha ao inicializar com um "nome do host: nome ou erro de serviço não conhecido". Eu suspeito que isso é devido a falha de uma pesquisa reversa de DNS no endereço IP "público" de instâncias. Isso parece correto? Qual é o problema?

    

Answer 1

As configurações public-bucket e public-bucket-url foram preteridas há algum tempo e são ignoradas. Apenas o control-bucket é usado, se especificado - caso contrário, é gerado aleatoriamente. O bucket privado é agora a única maneira de substituir ferramentas de juju com uma versão especificada a partir de dados simplestreams.

Por exemplo, executando juju bootstrap --upload-tools depois de garantir que você tenha executado o equivalente a:

# cd $GOPATH/src/launchpad.net/juju-core/cmd/juju # go install . # cd ../jujud # go install .

empacota os binários juju (juju e jujud) de $ PATH em um tarball de lançamento e carrega no control-bucket . Em seguida, o script cloud-init é executado quando a máquina de inicialização é inicializada, baixando e instalando as ferramentas atuais mais recentes (o que - upload-tools sempre garante). Então, juju bootstrap --upload-tools , se hacky é certamente útil para testar mudanças na fonte do juju-core em uma implementação real.

Como alternativa, você pode executar:

juju sync-tools --all --public --source=~/.juju/local/storage/tools/release/

logo após executar juju bootstrap -e local --upload-tools (supondo que você tenha executado os comandos 2 go install mencionados anteriormente, ao criar a partir da origem). Dessa forma, você precisará executar juju bootstrap -e local e observar o progresso / verificar os registros.