Вопрос Нужно ли добавлять метаданные изображения в личное ведро?


Я экспериментирую с использованием Juju (16.6) для развертывания служб для нашего частного облака Openstack и заметил пару проблем.

При начальной загрузке новой среды Juju, похоже, хочет посмотреть в ведро среды для метаданных изображений. Я создал «общедоступное» ведро, используя Swift для хранилища объектов, и заполнил его метаданными изображения в объектных путях «streams / v1 / *», однако, когда самозагрузка juju завершается с ошибкой, если метаданные не находятся в частное ведро окружающей среды. Это нормально? И есть ли проблема в конфигурации среды, чтобы решить эту проблему?

Моя среда выглядит следующим образом (меньше ключей 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

Как только я получаю среду для начальной загрузки, я затем попытаюсь открыть службу. В моем случае я использую шарм Hadoop. Когда я разворачиваю мастер хаоса (juju deploy hadoop hadoop-master), экземпляр не может инициализироваться с именем «hostname: name или service not known error». Я подозреваю, что это происходит из-за сбоя обратного поиска DNS на «общедоступном» IP-адресе экземпляров. Правильно ли это звучит? В чем проблема?


2
2018-02-20 22:47


происхождения


Можете ли вы включить полный журнал juju bootstrap --debug --show-log команда? Вы можете использовать paste.ubuntu.com и добавьте ссылку здесь (редактируя любые секреты до этого, конечно). - dimitern


ответы:


И то и другое public-bucket а также public-bucket-url настройки были устаревшими некоторое время назад и игнорируются. Только control-bucket используется, если указано - в противном случае оно генерируется случайным образом. Частное ведро теперь является единственным способом переопределить выборку инструментов juju с указанной версией из данных простейших потоков.

Например, juju bootstrap --upload-tools после того, как вы выполнили эквивалент:

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

упаковывает двоичные файлы juju (juju и jujud) из $ PATH в деблокирующий tarball и загружает его в control-bucket, Затем сценарий cloud-init запускается, когда загрузочная машина загружается, загружает и устанавливает самые последние текущие инструменты (которые всегда обеспечивают загрузку). Так juju bootstrap --upload-tools, если hacky, конечно, полезно проверить изменения в источнике juju-core в реальном развертывании.

Кроме того, вы можете запустить:

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

сразу после запуска juju bootstrap -e local --upload-tools (при условии, что вы запустили 2 go install команды, упомянутые ранее, при построении из источника). Таким образом, вам нужно будет запустить juju bootstrap -e local и следить за ходом / проверкой журналов.


2
2018-02-24 02:15



Я смог загрузиться с помощью управляющего ведра в Swift - заполнение путей объектов stream / v1 с помощью моих локальных метаданных изображения. Таким образом, проблема, с которой я сталкиваюсь при загрузке, - это где метаданные локального частного облачного изображения? В каталоге local / storage / tools / release? Однако узел, который я могу загружать, не может запускать дополнительные экземпляры. Это связано с тем, что записи DNS для общедоступных IP-адресов не присутствуют? - skibum
Бег juju sync-tools как описано в ответе, следует исправить ошибки загрузки и экземпляра экземпляра. - dimitern