Наверное, можно, но я так не хочу. Хочу нормальный отзыв ключей, PKI хочу. Одноранговые SSH не хочу. Вот и спрашиваю, есть ли нормальное что-то.

Подписывать ключи?

https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-with-ssh/

Ну да. https://libvirt.org/remote.html

То, что нужно. Как-то я упустил этот момент в libvirtd совсем. А не пробовал сам? Опенстек нормально работает при таком транспорте? Ну т.е. понятно, что там не должно быть проблем, просто уточняю.

То, что нужно. Как-то я упустил этот момент в libvirtd совсем. А не пробовал сам? Опенстек нормально работает при таком транспорте? Ну т.е. понятно, что там не должно быть проблем, просто уточняю.

https://jaormx.github.io/2017/testing-tls-with-nova-live-migration/

У этого мужика такое лицо, что не читая заметку можно понять, что все работает ок, лол

Спасибо 👍

А расскажите, кто как менеджит SSH ключи для libvirtd при live migration для OpenStack? Официальная дока говорит "создайте пару ключей и скопируйте их на все ноды". Это shitty way, как по мне. Как сделать получше, кто-нибудь знает?

FreeIPA. мы им весь аксес менеджим.

А как вы его состыковываете с деплоем этих ключей?

ну раскладывать/удалять - пофиг чем, хоть ансибл, хоть папет. а история и отзывы - через FreeIPA.

по сути раскладывать то нужно только приватный.

если ты его отзываешь - делаешь же какой-то новый и раскладываешь уже новый.

а пускать или нет в конкретном случае решает уже стандартная связка с ipa через pam.

товарищи, кто знает, каков сейчас статус murano?

Уже не разрабатывают

Меликян и его команда вроде больше им не загимаются

Все так, да. Вся команда разошлась.

Теперь тока сообщество штопает патчи

🙁

если ты его отзываешь - делаешь же какой-то новый и раскладываешь уже новый.

@sbog а я про что ;)

Это про TLS-ключи, не про SSH. В TLS тебе не надо absent делать в паппете, ты ключ в PKI просто в CRL добавляешь - и все, он больше не работает. Сразу. В этот же момент. Не надо с горящей жопой делать деплой на 1000 машин.

Плюс ты историю этих ключей хранишь, что бывает нужно.

Идея та же

Генеришь и деплоишь новый)

Идея не та же. В случае с SSH ключами ты повторяешь деплой, что не всегда возможно сделать быстро в больших окружениях. Ты обязан повторить деплой, чтобы отозвать старый ключ. А в случае с TLS ты просто отзываешь ключ в одном месте, причем это место создано для работы с этими ключами. И ты просто временно теряешь возможность миграции для одной машины. А потом уже делаешь деплой не спеша.

До кучи (мне лично не актуально, но все-таки) - ты можешь иметь один PKI и, скажем, 10 разных облаков, к которым у тебя даже доступа для деплоя нет. С ssh ключами ты начинаешь огребать. С tls ключами ты отзываешь ключ без деплоя.

Это упрощает с одной стороны, но усложняет настройку хоста. Тебе нужно и openssh конфигурировать и pam и возможно ещё что)

Да, разумеется. Плюс там возникает миллион вопросов к организации этого самого PKI. Это просто охренительно все усложняет.

И это, наверное, основной минус.

так что стоит подумать насчет простого scm+authorized_keys

привет) снова я с bgp =) у нас приватные сети с dualstack и когда создается подсеть для v6, она анонсируется через bgp агента. но в него прилетает такое: 2017-11-28 15:35:31.033 11088 DEBUG neutron_dynamic_routing.services.bgp.agent.bgp_dragent [req-15dd7f83-5f06-4f75-bbc4-838c3e078784 - - - - -] Received routes advertisement end notification for speaker_id=2f34c2ec-847c-47b5-a109-32f0c671c10d from the neutron server. bgp_ routes_advertisement_end /usr/lib/python2.7/dist-packages/neutron_dynamic_routing/services/bgp/agent/bgp_dragent.py:229 2017-11-28 15:35:31.034 11088 DEBUG neutron_dynamic_routing.services.bgp.agent.bgp_dragent [req-15dd7f83-5f06-4f75-bbc4-838c3e078784 - - - - -] Calling driver for advertising prefix: 10.254.66.0/24, next_hop: 2a02:5180:0:2704::7 advertise_route_via_bgp_speaker /usr/lib/py thon2.7/dist-packages/neutron_dynamic_routing/services/bgp/agent/bgp_dragent.py:467 и агент падает конечно: File "/usr/lib/python2.7/dist-packages/netaddr/ip/__init__.py", line 314, in __init__ % (addr, self._module.version)) AddrFormatError: base address u'2a02:5180:0:2704::7' is not IPv4 тоесть пытается анонсироваться v4 приватная подсеть с next_hop 2a02:5180:0:2704::7 хотя на роутере есть и v6 сеть. bgp-speaker создан с ip_version=6, после рестарта все анонсируется нормально, проблема в том что от neutron прилетает неправильное сообщение с next_hop от v6 но с сетью v4? багу сходу не нашел(

починил, добавив try.except в /usr/lib/python2.7/dist-packages/ryu/services/protocols/bgp/peer.py на self._send_outgoing_route() но это быстрое решение( надо все таки в нейтрон смотреть наверное, почему в раббит v4 сеть приходит с маршрутов v6

Привет, не подскажете в чем проблема, может кто сталкивался.Не получается создать в swift+radosgw два контейнера с одинаковыми именами под разными tenants. Например конт test21 При обращении получаю https://ххх.ru:8080/swift/v1/82cff387e99e464c9cf232a0285b10e7/test21 401 Unauthorized Хотя на 82cff387e99e464c9cf232a0285b10e7 контейнера test21 нет совсем. Он есть только на 8c4983dcb1fc41d1a18bc6a92c3e8be8 И к нему насколько понимаю логику обращение должно быть только через https://ххх.ru:8080/swift/v1/8c4983dcb1fc41d1a18bc6a92c3e8be8/test21

А все нашел rgw keystone implicit tenants была false в ceph.conf Если поставить true то для новых tenant создает корректно.

Ок, например "игровой хостинг", использую ваш клауд, киберкотлеты что-то не поделили, вам прилетело 400Mpps условно валидного трафика

вот умеешь ты нарисовать позитивную картинку :))

всем привет, кто-то подключал NetApp бекенд так чтоб работала и метадата и лайв миграция?

метадата, это которая в инстанс передается?

Эээ.

Нетапп по nfs?

у нас по FC

Специалисты по cloud-init есть? Мне надо странное. Сделать network-config disabled. Единственным способом который у меня получился это создать файл /etc/network/interfaces.d/99-disable-network-config.cfg и прописать в него network: {config: disabled} разные комбинации с прописыванием в user-data согласно разным документациям network-config={config: disabled} и network: config: disabled успеха не принесли. не то что бы меня прям парила генерация файла, но немного страдает чувство прекрасного. конфиг для cloud-init прилетает через ISO. И не спрашивайте зачем я так упоролся)

У кого-нибудь работает в проде схема когда OpenStack использует разные Ceph пулы ( HDD+SSD и Full SSD например) - как описано тут у Себастьена https://www.sebastien-han.fr/blog/2015/09/15/openstack-nova-configure-multiple-ceph-backend-on-one-hypervisor/ ?

Кажется достаточно сильно усложняет все такой вариант, возможно есть вариант проще.

всем привет! подскажите, какие компании в России сапортят openstack 24x7? цена поддержки интересна

аутсорс или интеграция?

аутсорс

Мирантис когда то занимался, думаю что ИТКей не откажется, могу познакомить. Мопед не мой ;)

На каком дистрибутиве кластер? Имеется в виду и Linux и OS.

в личке

ок

@SinTeZoiD у вас там вроде бы была продажа поддержки опенстэка

У кого-нибудь работает в проде схема когда OpenStack использует разные Ceph пулы ( HDD+SSD и Full SSD например) - как описано тут у Себастьена https://www.sebastien-han.fr/blog/2015/09/15/openstack-nova-configure-multiple-ceph-backend-on-one-hypervisor/ ?

У меня два цеф-пула использует cinder, там всё несложно. Запускать инстансы на недефолтном пуле правда приходится из предварительно созданного раздела на нужном volume-type

У меня два цеф-пула использует cinder, там всё несложно. Запускать инстансы на недефолтном пуле правда приходится из предварительно созданного раздела на нужном volume-type

Те разные image просто получается? А как в nova-compute.conf на гипервизорах это разруливается там же вроде один пул только можно указать (vms) ?

Те разные image просто получается? А как в nova-compute.conf на гипервизорах это разруливается там же вроде один пул только можно указать (vms) ?

Откройте для себя cinder и забудьте про эфимерные хранилища, как про страшный сон

Откройте для себя cinder и забудьте про эфимерные хранилища, как про страшный сон

Спасибо, ушёл курить маны

А кто-нибудь разворачивал это: https://github.com/redhat-openstack/openshift-on-openstack

У меня возникает ошибка при развертывании стека, когда создаётся bastion_host кейстоун куда то его не пускает.

Ну т.е. начинается создание стека, первым хостом в нем идет bastion_host, и вот когда идёт его создание heat выдает 2017-12-02 16:28:02Z [my-openshift]: CREATE_FAILED Resource CREATE failed: AuthorizationFailure: resources.bastion_host.resources.wait_handle: Authorization failed.

Есть знатоки Heat?

народ, а есть кто в openstack-ansible глубоко разбирается? это ппц, ну просто ад какой-то. начал с ним практически с нуля ковырятся, через 5-7 итераций (на виртуалках, которые откатываются на чистый снапшот) вроде разобрался практически со всем нюансами, все более-менее работало.но теперь уперся лбом просто. не может оно поднять опенстек, конфиг такой же как раньше был и все работало. теперь же все проходит отлично до плейбука setup-openstack, который валится на настройке heat контейнеров. причем heat он не может поднять потому, что галера в дауне, а она реально развалена уже на этом моменте до такой степени, что mariadb даже не стартует.

пробовал openstack-ansible из stable/pike, и просто руками последние теги из их репы - 16.0.4 и 16.0.3. косяк одинаковый. система - убунту 16.04

пробовал openstack-ansible из stable/pike, и просто руками последние теги из их репы - 16.0.4 и 16.0.3. косяк одинаковый. система - убунту 16.04

Бро, у меня такого же рода трабл, только на уровень выше (-: Похоже нам никто не поможет )-:

https://github.com/openstack/openstack-ansible/blob/master/playbooks/galera-install.yml — получается вот здесь где-то?

А ты где это запускаешь? Виртуалки в смысле?

виртуалки на esxi хостах. setup-hosts полностью успешно проходит. setup-infrastructure типа валится в первый раз - ругается на контейнеры галеры и ребита, но при этом проверка кластеров галеры и ребита проблем не показывает, кластера собраны. второй проход setup-infrastructure поверх - уже без ошибок. дальше setup-openstack проходит фактом до конца, устанавливает все компоненты кроме heat и horizon.

>>> виртуалки на esxi хостах Тяжелый случай. Ты их, получается, сбрасывал к ранним снимкам и там пробовал прокатить роль, в какой-то момент у тебя все накатывалось, а теперь перестало?

я сбрасываю практически на ноль все, в т.ч. deployment host. чтобы никаких хвостов.

Я бы повесил дебаги, для начала на сеть.

Посмотри как в ансибле, отправлять результаты в стандартный вывод.

Все ли репозитории доступны, для ансибля? Может когда ты раньше собирал, что то было доступно, а теперь упали репы какие-то?

я умею в ансибль. :)

проблема там явно в самих ролях openstack-ansible, опять какой-то ебучий нюанс видимо не учитываю. хотя конфиг элементарный.

Раз ты говоришь, что окружения одинаковые, значит надо искать разницу за пределами окружения. По-моему так.

а пакеты кешируются на repo контейнеры, оно бы падало раньше (и бывало кстати падало)

Что могло еще поменяться? Версии везде стоят latest небось?

окружения одинаковые, но обновлялся репозиторий openstack-ansible на гитхабе

вот есть такое ощущение что там что-то сломали. но доказать не могу. (

Ну попробуй откатиться к предыдущему коммиту и собрать.

Бро, у меня такого же рода трабл, только на уровень выше (-: Похоже нам никто не поможет )-:

На centos тоже самое ?

Ну попробуй откатиться к предыдущему коммиту и собрать.

вот перебираю теги, ага. сейчас 16.0.2 пробую. (

На centos тоже самое ?

Не, выше писал, про openshift (-: Это к тому, что в таких случаях, мало надежды на помощь.