И даже skip-list не используете?

Используем. Ipv6 не работает же в двр, смысл его прогонять?

т.е. вот этот тест у вас проходит и не скипуется?

tempest.api.compute.servers.test_multiple_create.MultipleCreateTestJSON.test_multiple_create[id-61e03386-89c3-449c-9bb1-a06f423fd9d1]

tempest.api.compute.servers.test_multiple_create.MultipleCreateTestJSON.test_multiple_create[id-61e03386-89c3-449c-9bb1-a06f423fd9d1]

Завтра зайди с этим же вопросом там полторы тысячи тестов )

Знаю, но поиск работает 😉

Поиск где?

Я тут как бы с телефона кнопки нажимаю

Ну вы репорты потом не сгружаете?

Нет ещё у нас пока один человек в них херачит, создавая сервис

@amyltsev вы там кстати синдер а докере с fc/iscsi схд используете?

Угу

Не ебет мозги? Мы года 3 назад пробовали и было не очень приятное зрелище )

Пока с fc нормально, но нагрузочные тесты мы ещё не гоняли

В то время оно не пробрасывало даже чёт девайсы

ковыряю maas+juju , пока на pods+visrh.  

Возник вопрос  , а реализован ли апгрейд openstack   релиза  ?

не оно
action-managed-upgrade / openstack-upgrade ?

https://jujucharms.com/openstack-dashboard/297
action-managed-upgrade
(boolean) If True enables openstack upgrades for this charm via juju actions. You will still need to set openstack-origin to the new repository but instead of an upgrade running automatically across all units, it will wait for you to execute the openstack-upgrade action for this charm on each unit. If False it will revert to existing behavior of upgrading all units on config change.

исходники с github

https://github.com/openstack-charmers/openstack-bundles/blob/master/development/openstack-base-bionic-stein/bundle.yaml

variables:  openstack-origin:    &openstack-origin     cloud:bionic-stein

https://github.com/openstack-charmers/openstack-bundles/tree/master/development/openstack-base-bionic-rocky

openstack-origin: cloud:bionic-rocky

Всем доброго вечера!
Подскажите plz, здесь можно задать вопрос про гипервизор (kvm)?

Да

История такая: есть несколько серверов на базе Intel(R) Xeon(R) Gold 6230 - это Skylake. При установке хост ос 4.14.35-1902.10.2.1.el7uek.x86_64 на одном из серверов virsh capabilities возвращал тип cpu skylake, а на других:
   <cpu>
     <arch>x86_64</arch>
     <model>Broadwell-noTSX-IBRS</model>
     <vendor>Intel</vendor>
     <microcode version='83886124'/>
     <topology sockets='1' cores='20' threads='2'/>
На данный момент на всех серверах почему-то показывает одинаково - архитектура Broadwell-noTSX-IBRS. Я заметил, что у процессоров отсутствует два флага - hle и rtm. Но почему и с чем это связано пока не разобрался. Не могу понять почему на одном из серверов сначала эти флаги были, а на следующий день пропали... Посмотрел ещё в /sys/devices/system/cpu/vulnerabilities:
itlb_multihit:KVM: Mitigation: Split huge pages
l1tf:Not affected
mds:Not affected
meltdown:Not affected
spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
spectre_v2:Mitigation: Enhanced IBRS, IBPB: conditional
tsx_async_abort:Mitigation: TSX disabled
Возможно с этим тоже связано. У кого skylake не гипервзорах, как ваш процессор выглядит? какое ядро, какие capatibilities и vulnerabilities ?

И вторая часть: на другой партии серверов с процами Intel(R) Xeon(R) Gold 5217 (тоже skylake), на том же ядре, той же установленной системе, те же версии пакетов как в первой группе серверов, при попытке запуска qemu libvirt возвращает ошибку:
invalid argument: KVM is not supported by '/usr/bin/qemu-system-x86_64' on this host

в какую сторону копать?

Как процессор выглядит зависит от версии qemu и того какую модель ты указываешь в конфиге для либвирта.

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

По второму вопросу включай log_level=1 в конфиге Libvirtd и смотри чо туда пишется при попытке запустить виртуалку.