зачем так сложно, ради 1 пакета? Ведь сеть может быть все еще не сконфигурена и на этапе packages: там никто не гарантирует этого! :)
Давай так, из практики клауд инит в кентос ждёт сеть и не двигает настройку дальше, ни разу не видел описываемых проблем
Fedor
Denis
Давай так, из практики клауд инит в кентос ждёт сеть и не двигает настройку дальше, ни разу не видел описываемых проблем
ты видимо не провиженил это через dhcp вне клауда и тебе везло, что ip отдали быстро)
Denis
я бы не полез туда так глубоко просто так
Fedor
ты видимо не провиженил это через dhcp вне клауда и тебе везло, что ip отдали быстро)
Не везло, эта конструкция стабильно ждёт сеть на всех интерфейсах
Fedor
Ладно, давай действительно завязывать с флудом, можно в личке дообсудить)
Denis
ага)
Dmitry
cloud-init не может зависеть от сети, он сам часто используется, чтобы сеть настраивать
Denis
cloud-init не может зависеть от сети, он сам часто используется, чтобы сеть настраивать
он и не зависит от сети
- он стартует раньше чем сеть
- в нем нет возможности установить required пакеты, это те, что до packages:, напрашивается использовать bootcmd
- bootcmd может быть исполнена, еще до инициализации сетевого стека! Собственно это подтверждает, что CI стартует до сети и никак не связан с сетью
- в итоге имеем, bootcmd ставит пакет epel-release, сеть еще инициализируется, yum падает, явный вызов nm-online помогает дождаться когда сеть проинициализируется и тогда команда в bootcmd исполнится уже с сетью, встанет нужный пакет, дальше packages накатит остальное
NS 🇷🇺
cloud-init не может зависеть от сети, он сам часто используется, чтобы сеть настраивать
как же не зависит, вот у вас не доступна мета по хттп, не важно по каким причинам, а конфиг драйв вы не подсовывали, откуда оно возьмет параметры?
Dmitry
ну если использовать метадату, то да
J
Я тк и не понял почему и на что жалоба то?
Andrey
как же не зависит, вот у вас не доступна мета по хттп, не важно по каким причинам, а конфиг драйв вы не подсовывали, откуда оно возьмет параметры?
откуда вывод что "конфиг драйв вы не подсовывали" - вся концепция строится на том что он есть
NS 🇷🇺
откуда вывод что "конфиг драйв вы не подсовывали" - вся концепция строится на том что он есть
У кого она строится и почему?
ᴅⁱᵐⁱᴅʳ0ˡ
Red Hat сделала свой знаменитый Linux-дистрибутив бесплатным - CNews
https://www.cnews.ru/news/top/2021-01-21_red_hat_sdelala_svoj_znamenityj
Fedor
Red Hat сделала свой знаменитый Linux-дистрибутив бесплатным - CNews
https://www.cnews.ru/news/top/2021-01-21_red_hat_sdelala_svoj_znamenityj
Бесплатно на 16 тазиков != бесплатно
ᴅⁱᵐⁱᴅʳ0ˡ
Везде есть свой подвох😁
Fedor
Так то есть некоторые сайты, где винда бесплатно без регистрации и смс, но покупаешь ты не это) Интересно, шапочный сабскришпн-манагер там же лежит, или нет.
Dmitry
Я так понял, subscription-manager надо всё равно использовать.
Keha
еще зеки не разворачивали опенстек
Eugen
ну да)) вон в истории сколько годноты
Eugen
возможно так и должно быть) я не замерял, но обычно минут 15-20 может разворачивать (зависит от выбранных компонентов)
Aleksey
Вопрос из раздела «я что-то сделал и что-то перестало работать». Есть логи, трейсы, ошибки?
NS 🇷🇺
Alexander
собрал образ для openstack, в нем изменил sources.list.
запустил вмку, но сработал cloud.init и переписал его из template.
а как отключить генерацию из template?
p.s. нашел
apt:
preserve_sources_list: true
J
Ну какой вопрос, такой и ответ.
Ты смотри чо происходит в это время.
У меня такое было когда я на флешку раскатывал всё, например.
J
Потому, очевидно, что флешка для интенсивных случайных операций вообще не приспособлена.
А у тебя может быть проблема в сети. А может тоже в диске.
Denis
Alexander
source.list.d жеж!
при добавлении в source.list.d остались основные ubuntu репозитории /etc/apt/sources.list. мне нужна только локальная репа
Denis
Artur
Парни, были ли у кого траблы , с деплоем пачки виртуалок ,при этом к примеру 8 разворачиваются, а 2 нет , зависая на стадии block device mapping , лимиты поднял, nova.conf
block_device_allocate_retries = 1200
block_device_allocate_retries_interval = 2
block_device_creation_timeout = 300 , основываясь на этой статье https://www.suse.com/support/kb/doc/?id=000019177, но проблема не ушла
Artemy
Проверь состояние волюмов. Если они creating - то а хрен ли ты хотел - смотри гланс и синдер. Если available - надо смотреть нову.
Artemy
если эфемерки - то сразу нову и тут "ну я уже не скажу"
Artur
схд dell , glance file в логах примерно VolumeNotCreated: Volume <volume_guid> did not finish being created even after we waited 187 seconds or 61 attempts. And its status is creating.
Artur
только таймауты выше
Artur
состояние volume creating в этот момент
Artemy
Ну вот значит не создался еще волюм. Смотри в синдере что он делает - скачал ли имадж развернул ли его и залил ли на сторадж
Eugen
Парни, были ли у кого траблы , с деплоем пачки виртуалок ,при этом к примеру 8 разворачиваются, а 2 нет , зависая на стадии block device mapping , лимиты поднял, nova.conf
block_device_allocate_retries = 1200
block_device_allocate_retries_interval = 2
block_device_creation_timeout = 300 , основываясь на этой статье https://www.suse.com/support/kb/doc/?id=000019177, но проблема не ушла
а сколько по времени от начала до ошибки проходит? (примерно)
Artur
ну если стандартные таймауты, то где то 10 минут , а так с большими после часа вывалится
Eugen
https://www.ibm.com/support/pages/concurrent-deploy-fails-due-volume-creation-timeout
но ведь выходит, что nova ждёт 1200 * 2 = 2400 секунд, и срабатывает timeout ?
Artur
ну да, я и больше попыток делал и таймауты поднимал, все равно тоже самое, только дольше ждешь
Artur
Eugen
хотя то, что 8 из 10 - более чем указывает на то, что проблема в таймаутах
Artur
да, только в какой то момент, их поднятие уже не играет роли, куда то еще упираемся
Artur
так как раньше даже 4 тачки без таймайтов бывало висло, а теперь 10 делаешь, виснет 2 =) но выше таймауты делаешь, не помогает
J
Artur
Да
Eugen
Да
т.е. на каком-то этапе увеличение таймаутов предварительно помогло созданию большего числа машин ?
J
схд dell , glance file в логах примерно VolumeNotCreated: Volume <volume_guid> did not finish being created even after we waited 187 seconds or 61 attempts. And its status is creating.
Вот это говорит о том что не в таймаутах дело.
J
Такое бывает когда glance качает образ добавленный по url и какой-нить ubuntu cloud archive внезапно рвет соединение.
Artur
т.е. на каком-то этапе увеличение таймаутов предварительно помогло созданию большего числа машин ?
да, а потом уже уперлись в другое что то, сейчас более детально логи посмотрю, когда ошибка выпадет , скину
J
Или когда криво копируются метаданные из образа в том и происходит конфликт ключей.
Artur
а сейчас все 10 тачек задеплоились(
Artur
какая то плавающая ошибка
J
а сейчас все 10 тачек задеплоились(
Ну так включи и собирай дебаг логи в glance и cinder до тех пор пока ошибка снова не проявится.
Artur
да, это не проблема, сейчас повторим fail
Pavel
у гланса кто бекенд хранения?
также рекомендую смотреть логи хранилки на предмет ошибок
187 seconds or 61 attempts - говорит о то что была ошибка от бекенда
Aleksey
ну ключи вроде как он закинул на эту ноду, а где установка пакетов, как на других нодах?
J
А у тебя ж дебаг лог не включен?
J
Я ж тебе второй или третий раз говорю, включи везде дебаг логирование. Тогда, глядишь, и причина ясна станет.
Aleksey
а зайти на ноду и посмотреть что там происходит?
J
Кого врубил?
Я про debug логирование в nova,cinder и glance.
Ilya
На всякий, логи сюда: https://etherpad.opendev.org
Ilya
Не надо полотна логов в чат 😀
Ilya
Кого врубил?
Я про debug логирование в nova,cinder и glance.
Так там в процессе установки виснет
Ilya
Один фиг - логи надо смотреть
Ilya
Такое ощущение, что пакеты не может скачать или развернуть
Artur
В общем , ошибка плавающая, то случается то нет, в логах 2021-01-28 15:33:36.670 7 ERROR nova.compute.manager [req-668b8a14-de6a-453a-b17f-36d828a5bd4b a6ea13b99d554e7a80e7757dcde25fa5 16df60af4d69470f881f4fb5f24aa3c4 - default default] [instance: 23b0f44a-7930-447a-a2ce-908c528372e8] Build of instance 23b0f44a-7930-447a-a2ce-908c528372e8 aborted: Volume 988574c1-6310-40f0-8739-3df4d714c429 did not finish being created even after we waited 3808 seconds or 1201 attempts. And its status is creating.: BuildAbortException: Build of instance 23b0f44a-7930-447a-a2ce-908c528372e8 aborted: Volume 988574c1-6310-40f0-8739-3df4d714c429 did not finish being created even after we waited 3808 seconds or 1201 attempts. And its status is creating.
Artur
в харайзене volume висит в статусе creating
Artur
1
Artemy
Ну вот значит твой сторадж не создал лун или не отрепортил что создал.