Удалось что нибудь увидить?))))

Неа, только вот это: 2023-08-11 09:39:33,847 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'type': 'physical', 'mtu': None, 'subnets': [{'type': 'dhcp4'}, {'type': 'ipv6_slaac', 'netmask': 'ffff:ffff:ffff:ffff::', 'routes': [{'network': '::', 'netmask': '::', 'gateway': '2a13:4ac0::1'}]}], 'mac_address': 'fa:16:3e:da:4c:55', 'name': 'eth0'}]} Как будто клауд инит RA распарсить до конца не смог, что ли. А как выглядит итоговый конфиг для интерфейса, который он генерирует?

Неа, только вот это: 2023-08-11 09:39:33,847 - stages.py[DEBUG]: applying net config names for {'version': 1, 'config': [{'type': 'physical', 'mtu': None, 'subnets': [{'type': 'dhcp4'}, {'type': 'ipv6_slaac', 'netmask': 'ffff:ffff:ffff:ffff::', 'routes': [{'network': '::', 'netmask': '::', 'gateway': '2a13:4ac0::1'}]}], 'mac_address': 'fa:16:3e:da:4c:55', 'name': 'eth0'}]} Как будто клауд инит RA распарсить до конца не смог, что ли. А как выглядит итоговый конфиг для интерфейса, который он генерирует?

Ну рано или поздно придется это делать, особено когда твой опенстек в роли паблик клауда будет

Не, прям покажи конфиг нетплана, который cloudinit сгенерировал.

Не, прям покажи конфиг нетплана, который cloudinit сгенерировал.

# Created by cloud-init on instance boot automatically, do not edit. # AUTOCONNECT_PRIORITY=999 BOOTPROTO=dhcp DEVICE=eth0 DHCLIENT_SET_DEFAULT_ROUTE=no HWADDR=fa:16:3e:6e:e8:cc IPV6INIT=yes IPV6_AUTOCONF=yes ONBOOT=yes TYPE=Ethernet USERCTL=no

Почему)?

Добро пожаловать в ipv6 на линуксах 🚬 Там основная проблема в образах. Мета содержит всё ок, а вот сами дистрибы- кривые часто

Добро пожаловать в ipv6 на линуксах 🚬 Там основная проблема в образах. Мета содержит всё ок, а вот сами дистрибы- кривые часто

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

Ну рано или поздно придется это делать, особено когда твой опенстек в роли паблик клауда будет

Или нет) По крайней мере, не раньше чем пердуны проектировавшие ipv6 не признают что были не правы вернувшись к классовой адресации со /64 префиксами на каждый интерфейс и не повинятся за свою любимую мантру "nat is not security mechanism and КОСТЫЛЬ"

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

Ну вот пример: образ убунты и дебиан. На deb ipv6 работает из коробки, ubuntu- нет

Ну вот пример: образ убунты и дебиан. На deb ipv6 работает из коробки, ubuntu- нет

Какой деб))?

Какой деб))?

10 вроде

Ну это уже я не знаю)) что там у тебя в манифесте))

так тут же используется DeamonSet который делает деплой на NodeSelector

так тут же используется DeamonSet который делает деплой на NodeSelector

тогда убей одну реплику

у DS нет реплик, он на них не ссылается.

если только оставить один лэйбл, но тогда если ноде придёт ппц то и switch тоже

а что тогда это 2/2

два из двух?

10 вроде

Дебиан

все тоже самое))

а что тогда это 2/2

это количество контейнеров в pod

это количество контейнеров в pod

Оуч)

понял

Ну а чем опенстек под эти задачи не подходит

просто интересно

Давайте рассмотрим другой вариант, когда бизнесу нужно реализовать cloud за год и нет бюджета в 1 лямм $

Давайте рассмотрим другой вариант, когда бизнесу нужно реализовать cloud за год и нет бюджета в 1 лямм $

идут реселлить do/vultr

идут реселлить do/vultr

😂😂😂

опенстак так то тоже нихрена не дешевый

я пока тангстен отложил в ящик, что-то всё долго это делать по уму

а потом посчитать на несколько регионов и там кошмар и ужос

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

когда задача сделать тупой л2- всё работает, спору нет, но когда что-то посложнее- ой всё

не сдержался

Как по мне для простых вм и vpc и лоадбалнсера стека за глаза хватает и вроде нет сильных проблем

кст, OVH пример который очень успешно использует стек для клауда

кст, OVH пример который очень успешно использует стек для клауда

у них там свой L3

у них там свой L3

🤷‍♂️

селектел тот же

ну кароче с openstack можна работать и нужно, я так считаю))

сказал тот который убил неделю на фикс ipv6 и так и не пофиксил😂

ну кароче с openstack можна работать и нужно, я так считаю))

а как чекнуть метадата подскажи плиз, реально не знаю

Понял, буду смотреть спасибо.

Всем привет! Подскажите, пожалуйста, если вдруг кто-то знает, куда копать. Есть стенд с openstack victoria. На 2-х хостах ubuntu 20.04 (контроллер и компьют нода). На каждом хосте 2 сетевые, менеджмент и provider (настроено как flat network). Проблема заключается в том, что при создании вм, она не получает ip самостоятельно, а если настроить его руками - видит только ip компьют ноды в этой сети. Сам openstack настраивался руками из пакетов по инструкции с офф сайта.

Для тестов использую образ cirros из той же доки.

Из ошибок вижу только такое

2023-08-11 14:03:09.704 793 WARNING nova.compute.manager [req-c109d5d1-25d8-4133-bcba-f718ffcdd041 7dc3f381be6a4349b04bddcf56cfe52d 19ee9923cc4a43529ee7f8c47346a2c3 - default default] [instance: 20150839-dc8b-42de-bd7a-dadaced1c7d4] Rece ived unexpected event network-vif-plugged-877865b9-9760-44a0-b80d-4d1dc59e9d81 for instance with vm_state active and task_state None. в логе nova-compute на гипере

Напанятна, рисуйте

Гадать на пачке непонятного происхождения конфигов? Может просто колой раздеплоится?

Да все можно, но я честно 3 раза читал что написано и не понял

А можно что бы оно просто работало?

Куда высылать?

Что, где?

Присылайте, разберёмся 😆 (не знаю, о чём речь, но каберне это хорошо)

Борис json schema пропускает v2 ? Для Нетворк конфиг ноды, а не инстанса

OpenStack packages for Ubuntu — документация Installation Guide https://docs.openstack.org/ru/install-guide/environment-packages-ubuntu.html

Репу взял отсюда

OpenStack Installation Guide — Installation Guide documentation https://docs.openstack.org/install-guide/

Подготавливал по этой инструкции

Ставил пакеты по этой: https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-victoria

Развернуто на 2 хостах. У каждого хоста 2 сети 10.0.100 и 10.129.0. Вторая используется как provider. Никакого ovs.

В логах явного криминала не вижу, кроме сообщений о неожиданном таске на подключение сетевого порта.

Я понимаю, как выглядят сообщения об ошибках

Вм стартует, но на ней нет сети. Сообщений об ошибках в логе тоже нет. Только варнинги как в примере.

2023-08-11 14:03:09.704 793 WARNING nova.compute.manager [req-c109d5d1-25d8-4133-bcba-f718ffcdd041 7dc3f381be6a4349b04bddcf56cfe52d 19ee9923cc4a43529ee7f8c47346a2c3 - default default] [instance: 20150839-dc8b-42de-bd7a-dadaced1c7d4] Rece ived unexpected event network-vif-plugged-877865b9-9760-44a0-b80d-4d1dc59e9d81 for instance with vm_state active and task_state None. в логе nova-compute на гипере

Сорри, не совсем понимаю что нужно

2023-08-11 14:03:07.040 651 INFO neutron.agent.securitygroups_rpc [req-ae6f39d9-93dc-4418-945a-b3e10435f6f3 - - - - -] Preparing filters for devices {'tap877865b9-97'} 2023-08-11 14:03:07.942 651 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-ae6f39d9-93dc-4418-945a-b3e10435f6f3 - - - - -] Port tap877865b9-97 updated. Details: {'device': 'tap877865b9-97', 'network_id': '66f97eb4-d21e-4475-ac 32-296d62e6910e', 'port_id': '877865b9-9760-44a0-b80d-4d1dc59e9d81', 'mac_address': 'fa:16:3e:c1:38:56', 'admin_state_up': True, 'network_type': 'flat', 'segmentation_id': None, 'physical_network': 'provider', 'mtu': 1500, 'fixed_ips': [ {'subnet_id': '6bced898-1761-413e-86c7-a2f778535463', 'ip_address': '10.129.0.169'}], 'device_owner': 'compute:nova', 'allowed_address_pairs': [], 'port_security_enabled': True, 'qos_policy_id': None, 'network_qos_policy_id': None, 'prof ile': {}, 'propagate_uplink_status': False} при поднятии в логе агента на гипере На контроллере из ошибок нейтрон-сервера только такое: 2023-08-11 14:07:41.474 1659 WARNING neutron.pecan_wsgi.controllers.root [req-b8e48beb-4713-419a-bcc0-0ec74a853df1 ead9513a14de477a9dc9653e30597b84 19ee9923cc4a43529ee7f8c47346a2c3 - default default] No controller found for: floatingips - returning response code 404: pecan.routing.PecanNotFound 2023-08-11 14:07:41.475 1659 INFO neutron.pecan_wsgi.hooks.translation [req-b8e48beb-4713-419a-bcc0-0ec74a853df1 ead9513a14de477a9dc9653e30597b84 19ee9923cc4a43529ee7f8c47346a2c3 - default default] GET failed (client error): The resource could not be found.

Ок, сейчас попробую черкануть.

там не ovs, а linuxbridge

=_= извините, пожалуйста, я мучаюсь уже несколько дней с этой херней. Ещё раз: в логах neutron-linuxbridge-agent на ноде ошибок нет. В логах neutron-dhcp-agent, neutron-linuxbridge-agent, neutron-linuxbridge-cleanup, neutron-metadata-agent, neutron-server на контроллере тоже ошибок нет.

единственное что вижу - периодические варнинги в neutron-server: 2023-08-11 19:42:14.431 1659 WARNING neutron.pecan_wsgi.controllers.root [req-2dfa62a6-f5eb-4fc1-989d-37bfcf9f461a ead9513a14de477a9dc9653e30597b84 19ee9923cc4a43529ee7f8c47346a2c3 - default default] No controller found for: floatingips - returning response code 404: pecan.routing.PecanNotFound

я пишу в сообщества, обычно только если совсем жопа и ни гугл, ни коллеги помочь не смогли.

Если на вм руками поднять порт и присвоить ip - начинает пинговаться нода, на которой запущена вм, но на этом всё. То же и с dhcp - он пингуется только на контроллере.

нода и контроллер внутри provider сети видят друг друга по ip

tcpdump видит запросы на соответствующих интерфейсах

listening on tap7392b995-af, link-type EN10MB (Ethernet), capture size 262144 bytes 19:01:55.286003 ARP, Request who-has openstack-controller-1.ru-central1.internal tell 10.129.0.143, length 28 19:01:56.290313 ARP, Request who-has openstack-controller-1.ru-central1.internal tell 10.129.0.143, length 28 19:01:57.290017 ARP, Request who-has openstack-controller-1.ru-central1.internal tell 10.129.0.143, length 28

при попытке пинговать с вм другие машины в сети