а тут mgmt

provider:PROVIDER_INTERFACE_NAME тут же требуют интерфейс провайдера

да, я все перепутал ( провайдер тут mgmt сеть, красная - стыковочная сеть, сорри ((

пятница... (

да у самого голова трещит

тогда верните как было (но адресацию все равно проверьте, адрес узла .0 при /24 маске не подойдет)

ну и давайте снова на ошибку посмотрим, какая будет...

Аналогичная

nova.exception.InternalError: Failure running os_vif plugin plug method: Failed to plug VIF VIFBridge(active=False,address=fa:16:3e:d9:6c:91,bridge_name='brq333b523f-10',has_traffic_filtering=True,id=a9214040-6489-467c-9562-fd983a5e34bd,network=Network(333b523f-10d9-4075-8569-e3785281335c),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tapa9214040-64'). Got error: [Errno 13] Permission denied: b'/var/lib/nova/tmp/nova-lock_bridge'

Аналогичная

хорошо... (что не новая)

[vxlan] enable_vxlan = true local_ip = OVERLAY_INTERFACE_IP_ADDRESS

а вы настраиваете "Option 1: Provider networks)? так?

Нет 2 вариант

Нет 2 вариант

ну если по доке все точно сделали, и '/var/lib/nova/tmp/nova-lock_bridge' путь весь доступен польз nova, то... включать Debug на neutron и смотреть еще лог

xena эпизодически ослит кролик error closing AMQP connection 60sec heartbeat итд причем коннекшен внутри контроллера памяти валом, cpu не занято

оно так всегда было, это не Xena

мне кажется я с сетями наворочил криво

в openstack

мне кажется я с сетями наворочил криво

проверьте прям построчно. Эта дока в целом рабочая

и кстати ещё момент

у меня автоматом этот путь не создался почему то

/var/lib/nova/tmp/nova-lock_bridge

только до tmp далее я сам создал директорию и дал права

только до tmp далее я сам создал директорию и дал права

после установки и запуска новы было только /var/lib/nova/ ?

var/lib/nova/tmp

/var/lib/nova/tmp/nova-lock_bridge

а nova-lock_bridge - файл

нет

нет

у меня так -bash: cd: /var/lib/nova/tmp/nova-lock_bridge: Not a directory

впрочем пустой ~# file /var/lib/nova/tmp/nova-lock_bridge /var/lib/nova/tmp/nova-lock_bridge: empty

Ребят, я может скажу токсичную вещь, но вот нам прямо обязательно всем читать попытки студентов выполнить лабораторную работу? Еще раз прошу прощения, уже просто кровь из глаз :(

Ребят, я может скажу токсичную вещь, но вот нам прямо обязательно всем читать попытки студентов выполнить лабораторную работу? Еще раз прошу прощения, уже просто кровь из глаз :(

Это о чем ты ?

Это о чем ты ?

О наболевшем.

О наболевшем.

Тогда закрывай документацию))

Темпест кто гоняет? На каком канкаренси?

Темпест кто гоняет? На каком канкаренси?

10 (подобрано империческим путем)

спасибо

Еще обнаружил, что в дашборде не отображаются Router кхм

через cli создал

что-то как-то со скрипом у вас всё

не могу не согласиться...)

не могу не согласиться...)

роадмэп --> схема сети --> внимание к доке --> syslog/Debug --> ??? --> PROFIT!!!

роадмэп --> схема сети --> внимание к доке --> syslog/Debug --> ??? --> PROFIT!!!

Спасибо, извиняюсь за беспокойство

@adiantum

Сорян, это был карман

Темпест кто гоняет? На каком канкаренси?

на 1 всегда делаю ( и -t ключ). имхо самое надежное, но долгое. бывает тесты мешают друг другу. кстати ещё хорошо зачищать артефакты, оставшиеся после упавших тестов прежде чем пускать полный прогон снова.

Надежное в плане получить 0 ошибок :)

Например 1 поток и ovn особенно свежая инсталляция покажет все ок. А вот если прогрузить потоками или сделать дцать проходов то сюрпризы выскакивают

Рейс конечно случается, не безрешно оно. Но в в основном вполне объективные причины.

Особенно забавно когда тест прошел успешно, но на клинапе теста не смогло, в итоге видим фейл

Зависимость количества гиперов и количество канкаренси не проглядывается?

Например 1 поток и ovn особенно свежая инсталляция покажет все ок. А вот если прогрузить потоками или сделать дцать проходов то сюрпризы выскакивают

для канкаренци тестов все ж ралли лучше

Это понятно, но Темпест тоже неплохо подсвечивает. Например детач волума залипает, а при удалении вм все ок. Для ралли до такого теста нужно додуматься. Просто как пример.

для канкаренци тестов все ж ралли лучше

угу. темпест- функциональные тесты. ралли -перфоманс, нагрузка

Это понятно, но Темпест тоже неплохо подсвечивает. Например детач волума залипает, а при удалении вм все ок. Для ралли до такого теста нужно додуматься. Просто как пример.

мину за 30 дописывается такой функционал )

Вопрос не в написании, а в нахождении куда и как палочкой тыкать

Темпест с разными канкаренси я рассматриваю как некий рандомизатор нагрузки

Темпест с разными канкаренси я рассматриваю как некий рандомизатор нагрузки

да можно и так. но у ралли удобнее и запускать и отслеживать именно многопоточную нагрузку. и отчет там на это заточен. и темпест тоже можно приспособить под такое, но придется дописывать, что обычно лениво, если уже есть готовое

Тут скорее вопрос к тому что должно охватывать тестирование. Если ралли условно в 100 потоков создает сети бутает вм, Темпест в 1 поток пусть 10 проходов дает по нулям. То вроде все ровно. Но если при этом начать делать параллельно некие манипуляции которые неожиданно начинают вызывать фейлы причем не каждый раз ? То как оценивать здоровье клауда

да можно и так. но у ралли удобнее и запускать и отслеживать именно многопоточную нагрузку. и отчет там на это заточен. и темпест тоже можно приспособить под такое, но придется дописывать, что обычно лениво, если уже есть готовое

Темпест и ралли это разные по целям тесты.

Темпест и ралли это разные по целям тесты.

Да, в курсе, спасибо. Но запретить использовать темпест не совсем для того, для чего он предгазначен, я не могу :)

Тут скорее вопрос к тому что должно охватывать тестирование. Если ралли условно в 100 потоков создает сети бутает вм, Темпест в 1 поток пусть 10 проходов дает по нулям. То вроде все ровно. Но если при этом начать делать параллельно некие манипуляции которые неожиданно начинают вызывать фейлы причем не каждый раз ? То как оценивать здоровье клауда

Ты можешь налететь на архитектурные проблемы именно темпеста, а не клауда и на его же баги. Это тебе про здоровье клауда ничего не скажет

Да, в курсе, спасибо. Но запретить использовать темпест не совсем для того, для чего он предгазначен, я не могу :)

А, ну это разумеется. Запретить закручивать шурупы молотком невозможно :)

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

Инструмент позволяет использовать распараллеливание, прямых указаний на то что при таком то количестве может разносить и это нормально не нашел.

Большие дяди из редхата и некоторые другие конторы предлагают канкаренси 4

При этом опять же нет отсылки, что если разнесет типа норм так бывает

С какого бока можно игнорировать поведение Клауда если он факапится на том или ином канкаренси в такое то количество заходов

То чтосфункциональный тест побочно имеет некую нагрузочную функцию - как бы и неплохо

Я же не пытаюсь через канкаренси померить производительность

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

Хоспади, да прогоните темпест по очереди с канкарренси 1 2 3 4 5 6 и так далее до того момента, пока количество сфейленных тестов не увеличится, это и будет ваш максимум для текущего облака.

У темпеста задача показать, что функциональность на месте, это не НТ ни разу.

Вопрос на скольки канкаренси не должно быть. И сколько проходов. Например канкаренси 4, 30 прогонов, половина 0, половина среднее 2 ошибки, максимум 5.

Причем первые 8 именно по 0

Вопрос на скольки канкаренси не должно быть. И сколько проходов. Например канкаренси 4, 30 прогонов, половина 0, половина среднее 2 ошибки, максимум 5.

я сейчас на 200+канкаренци ралли тестируюсь -)))

red hat rally пускает на 50

Я пока про теспест говорю

Т.к. он первый в цепочке тестирования

@pyToshka: @paper_planes_squad @Outlingo @vanez1985 @SinTeZoiD @asdrozd @adiantum @ftarasenko

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

Да это понятно, что просто разбиение на группы выполнения. Вопрос как интерпретировать результаты

Да это понятно, что просто разбиение на группы выполнения. Вопрос как интерпретировать результаты

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