J
так там все само) инфраструктуру поднимать для iscsi не надо. агент- таргет, а conductor - инициатор. Лишь бы ip связность была и файрволы iscsi пропускали.
NS 🇷🇺
опять ты не про наш случай :D
NS 🇷🇺
да так всякого хватает
Yuf
Никита а бареметал для чего используешь ? Ноды новые деплоишь ? Или как сервис для клиентов ?
Yuf
Или его только для деплоя НОД можно
Yuf
@nsuvorov
J
Или его только для деплоя НОД можно
Ты не меня, конечно, спрашивал, но я им только новые серверы готовлю. Было бы их столько чтоб можно было давать как сервис - так бы и сделал)
Yuf
Совсем никак ?))
Yuf
Для end юзверей?
Yuf
Ака клиентов
NS 🇷🇺
Да
Yuf
Дописали сервис ? Или он это из коробки умеет ?
J
Дописали сервис ? Или он это из коробки умеет ?
Он все что нужно умеет и так. Там только веб интерфейс красивый прикрутить бы.
Yuf
Типа развернуть любой image на чистой железке
NS 🇷🇺
Не любой, а подготовленный
J
Не любой, а подготовленный
config drive для метаданных используете?
NS 🇷🇺
Да
J
Да
Чот мне надоело с ним возиться. как руки дойдут, буду пробовать nocloud-net и http сервер в качестве иточника. Но там, конечно, несколько мелочей надо продумать типа изоляции метаданных одного клиента от всех остальных, чтоб никто чужие метаданные не глянул.
NS 🇷🇺
NS 🇷🇺
я ниже написал, что не не правильно изложил
Dmitry
Тогда кто чего не релизовал-то?
J
Тогда кто чего не релизовал-то?
Выяснили уже что все ок.
NS 🇷🇺
Тогда кто чего не релизовал-то?
ну я еще раз повторю, из контекста не дергайте фразы, а дочитайте
Nick
Добрый день! Есть следующая проблема: В одной из сеток автоматически не стартует метадата агент, руками поднимается без проблем. Также dhcp агент в этой сетке никак не хочет привозить на виртуалку маршрут для метадаты(как и все остальные маршруты). В opts все маршруты описаны как надо. Рестартил все службы на контроллере - не помогло. Подскажите пожалуйста в чем может быть причина и по каким ключевым словам стоит поискать в логах. Проблему обнаружили в результате перезагрузки виртуалки, только в одной сетке
Nick
сумимасен, сам разобрался. Ребята включили свой dhcp на железках
J
сумимасен, сам разобрался. Ребята включили свой dhcp на железках
Подробнее поясни, пожалуйста, как так вышло и что наблюдал)
Nick
Просто коллега внимательно глянул в логи виртуалки и увидел там сообщения от dhclient, где dhcprequest уходит на адресс отличный от адреса наших агентов на контроллере)
Nick
оказалось что другие ребята захотели вставить в сетку железный хост и включили свой dhcp
Nick
Вообще ход диагностики (MOS 9.0): 1. ip netns exec <network id> netstat -ntlp на 80 порту метадата агент не слушает. Порестартил сервис метадата агента, поубивал процессы руками, понял что в других неймспейсах всё ок 2. стартанул руками метадата агент в неймспейсе на обоих контроллерах ip netns exec qdhcp-9e469133-0163-4ae3-8790-1472d11387d5 /usr/bin/python2.7 /usr/bin/neutron-ns-metadata-proxy --pid_file=/var/lib/neutron/external/pids/9e469133-0163-4ae3-8790-1472d11387d5.pid --metadata_proxy_socket=/var/lib/neutron/metadata_proxy --network_id=9e469133-0163-4ae3-8790-1472d11387d5 --state_path=/var/lib/neutron --metadata_port=80 --metadata_proxy_user=122 --metadata_proxy_group=130 --verbose --log-file=neutron-ns-metadata-proxy-9e469133-0163-4ae3-8790-1472d11387d5.log --log-dir=/var/log/neutron В логах всё ок. Агенты на разных контроллерах друг-друга видят. 3. Посмотрел в логах машины что клауд инит не привозит маршруты. Посмотрел /var/lib/neutron/dhcp/9e469133-0163-4ae3-8790-1472d11387d5/opts. Всё ок, погрустил. 4. Рестартанул все сервисы на контроллерах и снова запустил метадата агент руками, снова погрустил 5. Коллега нашел в логах машины dhclient[1124]: DHCPACK from какой-то-левый-адресс 6. ... 7. PROFIT
J
Вообще ход диагностики (MOS 9.0): 1. ip netns exec <network id> netstat -ntlp на 80 порту метадата агент не слушает. Порестартил сервис метадата агента, поубивал процессы руками, понял что в других неймспейсах всё ок 2. стартанул руками метадата агент в неймспейсе на обоих контроллерах ip netns exec qdhcp-9e469133-0163-4ae3-8790-1472d11387d5 /usr/bin/python2.7 /usr/bin/neutron-ns-metadata-proxy --pid_file=/var/lib/neutron/external/pids/9e469133-0163-4ae3-8790-1472d11387d5.pid --metadata_proxy_socket=/var/lib/neutron/metadata_proxy --network_id=9e469133-0163-4ae3-8790-1472d11387d5 --state_path=/var/lib/neutron --metadata_port=80 --metadata_proxy_user=122 --metadata_proxy_group=130 --verbose --log-file=neutron-ns-metadata-proxy-9e469133-0163-4ae3-8790-1472d11387d5.log --log-dir=/var/log/neutron В логах всё ок. Агенты на разных контроллерах друг-друга видят. 3. Посмотрел в логах машины что клауд инит не привозит маршруты. Посмотрел /var/lib/neutron/dhcp/9e469133-0163-4ae3-8790-1472d11387d5/opts. Всё ок, погрустил. 4. Рестартанул все сервисы на контроллерах и снова запустил метадата агент руками, снова погрустил 5. Коллега нашел в логах машины dhclient[1124]: DHCPACK from какой-то-левый-адресс 6. ... 7. PROFIT
Ну понятно) Спасибо)
Jaroslav
Изоляции image для bare metal деплоя как я понимаю нет не по http не по iSCSI? Т.е. автоматом ставим чистую ОС, дальше клиент автоматизацией допиливает?
Jaroslav
Не понял твоего вопроса.
В смысле все image для деплоя будут доступны всем клиентам? Хотя на файловую систему или http можно права навесить. Туплю.
J
как сделаешь, так и будет. Надо публичный образ? - ок. надо чтою юыл видим только конкретному клиенту? - сделай не публичным.
NS 🇷🇺
коллеги, никто не встречал такого, что сервер лист столбец нетвор выдает пустой по всем машинам. у одной машины нова интерфейс лист говорит, что есть 4 инта, вирш говорит что нихрена нету, сервер шоу тоже нифига не видит
Pavel
если vm прибили руками/oom то nova ничего не знает об этом. Синхронизация идет только во время создания VM и еще пары сценариев.
NS 🇷🇺
ее не прибивали
NS 🇷🇺
оно просто потеряло инты
NS 🇷🇺
да и как бы при хардребуте xml перегенерится, но она создается без интов
Pavel
тоесть вм работат но ее не видно.
NS 🇷🇺
вм работает, но у нее нет сетевых интерфейсов
NS 🇷🇺
как там база? чего в логах про синк ежеминутный?
база жива.... синь вроде тоже ничего криминального не дает
Dmitry
база жива.... синь вроде тоже ничего криминального не дает
а запрос руками в базенку? отдает что нужно?
NS 🇷🇺
а запрос руками в базенку? отдает что нужно?
до исходников я еще не дошел, чтобы запросы взять =)
Ascandar
а kolla-ansible насколько production ready проект?
NS 🇷🇺
а запрос руками в базенку? отдает что нужно?
у свеженьких все ок... скорее всего запрос добегает в нужное место
Dmitry
у свеженьких все ок... скорее всего запрос добегает в нужное место
а у стареньких пусто? где то неконсистентность. хард ребут на вируталки не помогает?
NS 🇷🇺
Тогда смотри временные таблицы
Да завтра постараюсь прошерстить. Люблю ебанутые кейсы)
Dmitry
Опс один большой фреймворк ебанутных кейсов
Pavel
Разве алхимия бы не ругалась, если бы небыло места на временные таблицы?
Arkadiy
а kolla-ansible насколько production ready проект?
Делоит нормально, конфигурирует нормально, контрибьют принимают быстро (если пушить ptl в irc)
Pavel
Дак а что с ними ещё может быть. Места не хватило, больше чем разрешено, права доступа
Dmitry
Дак а что с ними ещё может быть. Места не хватило, больше чем разрешено, права доступа
там же есть некоторые кэширующие таблички типа nova.instance_info_caches. - вот там можн опосмотреть запись по instance_uuid
Dmitry
там радостно подвисает инфа в случае проблем с базой
Pavel
збс
NS 🇷🇺
NS 🇷🇺
затрахало чет с ветряными мельницами бороться :D ... ни у кого нет отсылки в код, где нова дергает инфу из нейтрона?
NS 🇷🇺
ну тут у меня печально, народ начал хард ребуты делать и естественно машины стали без интов подниматься =(
Pavel
затрахало чет с ветряными мельницами бороться :D ... ни у кого нет отсылки в код, где нова дергает инфу из нейтрона?
предполагаю, что где-то тут https://github.com/openstack/nova/blob/f7b98a9201e37d6f6992ae62c67335022af28c8f/nova/network/neutronv2/api.py#L369
NS 🇷🇺
таблица с кешами не обновляется сука...
Dmitry
Мож залочил кто?
NS 🇷🇺
не, руками я в нее резво могу
NS 🇷🇺
с бекапа две машины поднял
Vladislav
Проблема с поврежденным instance_info_cache известная, её исправят к Stein (наверное), смотрите https://review.openstack.org/#/c/591607/
Dmitry
😫
Vladislav
И разработчики Nova с этой проблемой уже году в 2015 боролись. Поправили, но затем отревертили фикс коммитом https://github.com/openstack/nova/commit/8694c1619d774bb8a6c23ed4c0f33df2084849bc , с тех пор instance_info_caches не восстанавливаются, если с ними что-то случилось.
J
И разработчики Nova с этой проблемой уже году в 2015 боролись. Поправили, но затем отревертили фикс коммитом https://github.com/openstack/nova/commit/8694c1619d774bb8a6c23ed4c0f33df2084849bc , с тех пор instance_info_caches не восстанавливаются, если с ними что-то случилось.
Чот бедовые они. Заходишь почитать комменты к какому-нить изменению на геррите и будто в паспортный стол попал какой-т. Так нельзя, эдак не годится, падажжи, старшой ушел на обед, а у вас бумажки вон ентой нету, потому вертели мы ваш коммит. Ой, мерж виндоу этого релиза закрылся, приходите завтра, авось к следующему релизу пропихнете, если убедительно ныть будете.