Я экспортер в Прометей смотрел

Ок, пойду глаза проверю

А этого митапа можно как-то избежать или мы обречены?

если в кластере кролика отваливается нода, то как-то колбасит или всё прозрачно проходит ?

Когда как. Зависит от инсталляции. Каждый сервис может к разным нодам быть подцеплен, и может случиться так, что на одном контроллере к одному кролику, на другом к другому. Вот и выходит, что из трёх запросов два нормально работают, а один тормозит. В общем бывают чудные случаи.

Это релиз опенстека Ocata еще, выходит?

train

train

Тебе нужен как минимум ussuri либо патчить Libvirt драйвер. Переносить код метода swap_volume из более свежих релизов к себе. https://opendev.org/openstack/nova/src/commit/4eaceeec4d0c7a37cfed1194d02a403c057d0af3/nova/virt/libvirt/driver.py#L1892

Мдасс, не тривиально. Я разные версии еще не тянул в инсталяцию. Хотя знаю что так можно. Максимум что делал, патчил neutron.

https://github.com/kbudde/rabbitmq_exporter

а не пробовали стоковый кролевый экспортер? или типа "этот работает - нет смысла менять"?

О чем я и говорил. У тебя завалил запрос capabilities filter. То есть скорей всего спецификация типа волюма не совместима с атрибутами бакэнда cinder get-pools -d и сравнивай с openstack volume type show, чтобы все что написано у типа в extra_specs было написано и у пула пропертях

Че пацаны с 256ым днем что ли -)))

Че пацаны с 256ым днем что ли -)))

ааа точно ))) ну пофиг )) все равно надо нажраться

Через харайзон льете ?

Ого, заумь какая :)

Это у нас сделано😉

а, ну хоть ты расскажи как вы это запилили. А то Aleksandr пропал =) А @Outlingo предлагает грязные хаки в код, для поддержки всякого =)

Упс, я не так понял. Я про сinder-volume HA.

мы тож про него

Так ты же мне и помогал.

Понятно, у тебя короче как у меня =)

Ага, работает без накреканий. По логам было видно, что диски создаются на разный контролах.

ну там пацаны за подвисшие таски и связанные с ними проблемы. Но я пока не встречал

Возвращаясь к теме. Артемий правильную проблему подсветил. Глянул в коде. (кстати объекты циндера вроде не удаляются - а устанавливаются в состояние ошибки.) Т.е. поведение будет именно такое - при рестарте одного из сервисов циндер вольюм он заклинапит все воркеры (ака джобы циндера), которые были активны на момент старта циндер-вольюма. Т.е. в обсуждаемой конфигурации при рестарте одного циндер вольюма - если другие циндер-вольюмы чем то занимались - то эти задачи будут заклинаплены - т.е. например создаваемые тома будут установлены в error.

На Victoria работает, скоро на Wallaby посмотрю

у меня кстати не получилось такое поведение реплицировать с таким конфигом. В еррор уходят только треть джобов, как раз те, которые были зашедулены на ребутающийся контроллер

Это у нас сделано😉

у меня кстати не получилось такое поведение реплицировать с таким конфигом. В еррор уходят только треть джобов, как раз те, которые были зашедулены на ребутающийся контроллер

А поконкретнее можно кейс описать ? Что ребуталось ? И какие джобы уходиди в еррор (на какой сервис они в этот момент были зашедулены) ? Просто при создании тома апи сначала кастит через кроля в шедулер. Затем после того, когда шедулер кастит создание тома в конкретную очередь -ее берёт какой-то из вольюмов (в нашей конфигурации). В таблице воркеров появляется запись. И это тот момент, когда надо ловить рестарт. В лабе - и то не очень удобно так подловить циндер :)

запустил создание 100 вольюмов больших, сделал docker restart cinder_volume на одной из контролов, примерно 33 вольюма ушло в еррор, остальные нормально продолжили создаваться

я так понял airship 2й никто не осилил? Я что-то читаю доку и вообще понять не могу как с этим работать. Можно ли как-то развернуть тестовый стенда на ВМ?

bifrost не из этой же оперы ?

Просто нужна еще одна дырка в голове что говно вытекало в виде кастомайза

s3browser, Cyberduck