гость точно выключался

было примерно так: гость выключился пропало управление IPMI гость включился вернулось управление IPMI ironic пошёл и привёл в состояние shutoff

Управление могло пропасть если один и тот же физический интерфейс используется и для ipmi и для обычного трафика.

Всем привет! Пробую разлить magnum. Создается стек,лб, мастер-нода и на этом все останавливается. Computы кубера не хотят создаваться, Ussuri, в качестве ОС для кубера - fedora33, network dirver - calico. Подскажите как правильней продиагностировать и что мешает перейти к следующему шагу и начать создавать ноды кубера ?

астрологи объявили неделю кубов :)

кто в курсе, если ironic потерял node, то по какой фиче он идёт и вырубает nova server в состояние SHUTOFF (была ACTIVE). Можно ли этим управлять как-то и как называется опция?

В мейтенанс переведи ноду и она не будет синкать статус питания

Всем привет! Пробую разлить magnum. Создается стек,лб, мастер-нода и на этом все останавливается. Computы кубера не хотят создаваться, Ussuri, в качестве ОС для кубера - fedora33, network dirver - calico. Подскажите как правильней продиагностировать и что мешает перейти к следующему шагу и начать создавать ноды кубера ?

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

в инстансах нет инета?

config file neutrona есть?

пожскажите, а это норм, что свежая и почти пустая (3 ВМ и 10 сетей) инсталляция openstack (train, rhosp16.1) отвечает на 'openstac network list' или 'openstack server list' или image list итд около 6-8 секунд? ну и как следствие horizon не выглядит очень уж резвым

ее смотреть/ковырять, да?

пожскажите, а это норм, что свежая и почти пустая (3 ВМ и 10 сетей) инсталляция openstack (train, rhosp16.1) отвечает на 'openstac network list' или 'openstack server list' или image list итд около 6-8 секунд? ну и как следствие horizon не выглядит очень уж резвым

А что в логах?

блин. вы знали!

там пролетает пачками oslo_db.exception.DBConnectionError: (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query')

Лимит подключений в mysql какой?

блин, какая-то неведомая фигня. даже ТП кажется не понимает как я этого достиг :-\

там пролетает пачками oslo_db.exception.DBConnectionError: (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query')

может фиревол какой режет долгие коннекты?

Всем привет! Пробую разлить magnum. Создается стек,лб, мастер-нода и на этом все останавливается. Computы кубера не хотят создаваться, Ussuri, в качестве ОС для кубера - fedora33, network dirver - calico. Подскажите как правильней продиагностировать и что мешает перейти к следующему шагу и начать создавать ноды кубера ?

все огонь. iperf, ping в т.ч. с разным mtu и тд проверял

падает все на этапе kube_masters 2021-05-24 12:48:04Z [tdv001-uuasyk2rpupt.kube_masters]: CREATE_FAILED CREATE aborted (Task create from ResourceGroup "kube_masters" Stack "tdv001-uuasyk2rpupt" [e54b6cf8-0f5d-4ea5-9eef-8c0951818a1d] Timed out)

Поскольку кластер не совсем упал, то явно что какая-то часть траффика летит не туда или где-то дропается. Надо еще L3 связность между всеми хостами проверить, а то может у одного хоста шлюз по умолчанию в другой сети :)

Данила, привет ! стек не создался за отведённое ему время скорее всего, потому что ресурсы стека не создались -висят в непонятном состоянии скорее всего - беги по ресурсам и ищи зависшие

чес. слово - все перепроверил. mtu на всех серверах одинаковое, роутинг не при делах, т.к. этот трафик через internal-api vlan ходит

Не - это плохая проверка МТУ. надо пропинговать хотя-бы большими пакетами. На сетевом оборудовании тоже МТУ могут не то выставить... Если большие пакеты ходят - то тогда можно считать, что с МТУ +- всё ок

15k пакеты достато большие? =)

Илья, привет!) Да, у меня разливается master нода, на нее ставятся ресурсы куба и дальше тишина, и не понятно почему. Пробовал трафик снифать, но ничего информативного не нашел для себя. Сервисов в failed state нету при этом

openstack stack list --nested что показывает?

create_failed, и дальее по двум командам выше - что kube_master ресурс не создался корректно

Насколько я понимаю, хит сам следит за скриптом по коду возврата и похоже по таймауту. И дальше следует смотреть конкретный проблемный stack. Если скрипт в принципе начал работать, то в логе должно быть что-либо осмысленное.

А на вмку с мастером можно зайти и глянуть там логи?

Это, кстати, тоже может облегчит диагностику. Если при создании coe cluster прописать ssh ключ, можно будет заходить на вм-ки осмотреться. Не уверен правда, лежат ли логи хит скриптов где-либо внутри.

Да, я прокидываю ключик

В таймаут может уходить в попытке скачать какой-нибудь куберовский образ, который более недоступен. Или ещё по сотне причин. В magnum скриптах много что написано скажем так... "неаккуратно".

Есть у кого-нибудь Виктория с эфемерками и образами в cinder ?