Ну и, видать, оно говнится потому что внутри ISO есть GPT разметка. @a4860 Скинь на какой-нить pastebin лог glance со включенным дебагом. Так проще, наверное, будет понять как format inspector работает и где спотыкается.

https://docs.openstack.org/releasenotes/oslo.utils/2024.2.html

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

Ну и, видать, оно говнится потому что внутри ISO есть GPT разметка. @a4860 Скинь на какой-нить pastebin лог glance со включенным дебагом. Так проще, наверное, будет понять как format inspector работает и где спотыкается.

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

дык стоял текущий master, где код этих патчей уже был применен. Все равно проблема та же проблема. Может действительно из-за ceph-а, хотя в нем видно что в момент создания image, образ заливается

подскажите, какой правильный путь применять патчи в докер контейнерах? внутри контейнера код только для чтения. https://review.opendev.org/c/openstack/nova/+/931833

подскажите, какой правильный путь применять патчи в докер контейнерах? внутри контейнера код только для чтения. https://review.opendev.org/c/openstack/nova/+/931833

Тебе её нужно попробовать в false поставить.

стоп. секция..

поставил, но увы, не помогло

Секция [image_format], опция require_image_format_match То есть, вот так в конфиг вписать [image_format] require_image_format_match = False

там list должен быть? пробовал ['mbr','gpt','iso']

Да, я затупил)

там list должен быть? пробовал ['mbr','gpt','iso']

Не работает, короче, эта опция?

Ну тогда да, чот типа вот этого надо попробовать. https://review.opendev.org/c/openstack/oslo.utils/+/931695/1/oslo_utils/imageutils/format_inspector.py

Ручками можно поставить любой пакет в контейнере

Это понятно, думал, может в global.yml что-то не донес )

Я там логики не понял, но запускал коллу из собранного контейнера и ловил такую же шляпу ... потом поставил тупо пакетики коловские в виртуалку и с нее раскатал без этих ошибок не меняя каких либо конфигов. Что за прикол, пока не копал

амфетамины до добра не доведут..

но соглалось странная херня и ошибка в итоге возникает на удаленное стороне =)

один сетевой интер-с , это ВМ. доступ к порту марии и кролика из других контейнеров есть. в конфиге есть всё необходимое для подключения.

а с сетями все ок?

wsgi - это nova API. Ему на сети (объективно) наплевать с высочайшей башни. Надо запускать этот контейнер вручную в форграунде, лезть в него и смотреть чего он там пускает и как падает

wsgi - это nova API. Ему на сети (объективно) наплевать с высочайшей башни. Надо запускать этот контейнер вручную в форграунде, лезть в него и смотреть чего он там пускает и как падает

Сырой проект, бывает.

Парни есть вопрос, Kolla-ansible 2024.2 Можно ли првести установку HAproxy&Keepalived на отдельные ноды. Без других сервисов. При этом чтоб не править системные роли. Вот я не как не разобрался.

Всем привет. Подскажите пож начинающему по сетевой части. Ставил с опцией cat /etc/kolla/globals.yml |grep bond0 kolla_external_vip_interface: "lan-bond0" neutron_external_interface: "lan-bond0" lan-bond0 это 802.1q транк в сеть. Предполагается, что на стороне опенстека будут нарезаны разные vlan сети и включены в корп сеть. Создал такую сеть (vlan 40), а в физической сети в этот vlan смотрит аппаратный роутер своим vlan40 (на нем тоже транк и vlan40 тегируется) интерфейсом. Сделал тестовый инстанс в эту сеть, но пинги не ходят. tap интерфейс создается и включается в br-int, но MAC-а нет. (openvswitch-vswitchd)[root@cl-hpv-1 /]# ovs-appctl fdb/show br-int port VLAN MAC Age (openvswitch-vswitchd)[root@cl-hpv-1 /]# (openvswitch-vswitchd)[root@cl-hpv-1 /]# ovs-vsctl show 2fdc987f-e256-42d1-8c20-d6954e61bb48 Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-ex Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port br-ex Interface br-ex type: internal Port lan-bond0 Interface lan-bond0 Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port br-int Interface br-int type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Port qvofef02bf7-d6 tag: 2 Interface qvofef02bf7-d6 Bridge br-tun Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port br-tun Interface br-tun type: internal (openvswitch-vswitchd)[root@cl-hpv-1 /]# Что можно потыкать, где-то фреймы блокируются? Секгруппа так выглядит openstack security group rule list 5336c39c-7f66-4a2c-a43b-13c1e53abd56 +--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+ | ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote Security Group | Remote Address Group | +--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+ | 1f745439-3f68-487f-b4a5-39d93fb1ee4d | tcp | IPv4 | 0.0.0.0/0 | 8000:8000 | ingress | None | None | | 2d151041-d76d-4896-82b0-dfa8f0f1badd | None | IPv4 | 0.0.0.0/0 | | ingress | 5336c39c-7f66-4a2c-a43b-13c1e53abd56 | None | | 3809a882-dc02-407b-8a67-51cb6aa6060d | None | IPv6 | ::/0 | | ingress | 5336c39c-7f66-4a2c-a43b-13c1e53abd56 | None | | 55e08995-b85e-43bc-8c00-3fb4b4471c5f | tcp | IPv4 | 0.0.0.0/0 | 8080:8080 | ingress | None | None | | 62819be4-ddb8-4645-84c2-145f1f3c480f | tcp | IPv4 | 0.0.0.0/0 | 22:22 | ingress | None | None | | 92536936-2185-4026-8c12-25f986c6996d | None | IPv6 | ::/0 | | egress | None | None | | a1d7d416-a8e3-433d-a255-2469d49d37c6 | icmp | IPv4 | 0.0.0.0/0 | | ingress | None | None | | bfff0817-8ece-40dd-bfc9-eb13ebee8082 | None | IPv4 | 0.0.0.0/0 | | egress | None | None | +--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+ Только разбираюсь с сетью опенстека, до этого был чистый libvirt с linuxbridge

kolla_external_vip_interface: "lan-bond0" - тут нужен конкретный vlan для для API аля lan-bond0.400

ну это один хрен не причина проблемы =)

откуда куда пинга нет? Адрес назначен на вм по дхцп или вписан руками? если руками, то он совпадает с тем адресом, что заюзал нейтрон?

глаза режет)

нет пинга с инстанса на роутер. назначил руками вне диапазона subnet

kolla_external_vip_interface: "lan-bond0" - тут нужен конкретный vlan для для API аля lan-bond0.400

изменить и применить можно или нужно редеплой делать (с потерей настроек?) ?

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

с потерей.

памяти :D чего там потеряется то? ничего, просто интерфейс в конфигах изменится

и головного мозха.. потому что редеплой с вланами явно пойдет не по плану

те openstack port show PORT ID и адрес внутри инстанса у вас разные?

да. в ВМ назначен .10 а тут .126 fixed_ips | ip_address='192.168.142.126', subnet_id='1563adf4-c4db-47fc-b04d-1c456805e6a8'

Кто ни будь сталкивался с такой проблемой. openstack zed поднятый на сервисах. Бэкэнд ceph. При создании вм синдер привязывает том к ноде (например node5@ceph#ceph) при отключении данной ноды 1) не происходит эвакуация 2) нельзя мигрировать том на другую ноду. Включаю ноду все переезжает и вм эвакуируеться. (И тома мигрируют межу нодами) Если вм создаю на ноде, а том привязан к другой(При отключении ноды тоже все эвакуируеться) Но если вм лежит на той же ноде и том синдером прикреплен к этой ноде(то ни чего не переезжает) проверки томов и реплик цеф проверял. Тома доступны, волюмы не в блеклисте. Да права есть для клиента чтоб он мог управлять блеклистом

Кто ни будь сталкивался с такой проблемой. openstack zed поднятый на сервисах. Бэкэнд ceph. При создании вм синдер привязывает том к ноде (например node5@ceph#ceph) при отключении данной ноды 1) не происходит эвакуация 2) нельзя мигрировать том на другую ноду. Включаю ноду все переезжает и вм эвакуируеться. (И тома мигрируют межу нодами) Если вм создаю на ноде, а том привязан к другой(При отключении ноды тоже все эвакуируеться) Но если вм лежит на той же ноде и том синдером прикреплен к этой ноде(то ни чего не переезжает) проверки томов и реплик цеф проверял. Тома доступны, волюмы не в блеклисте. Да права есть для клиента чтоб он мог управлять блеклистом

ну вот и ответ. они должны быть ОДИНАКОВЫЕ, по дефолту поведение такое.

назначил ВМ .126, не помогло. видимо в чем-то ином причина. но, появился MAC (openvswitch-vswitchd)[root@cl-hpv-1 /]# ovs-appctl fdb/show br-int port VLAN MAC Age 4 2 fa:16:3e:4d:40:58 37 (openvswitch-vswitchd)[root@cl-hpv-1 /]# ovs-appctl fdb/show br-ex|grep 40:58 2 40 fa:16:3e:4d:40:58 56

ну значит тупо не одна проблема, а букет

ну значит тупо не одна проблема, а букет

не должно, еще не успел нарвать:)

а что за vlan2

хз, я так понял это внутренее опенстековское