1) Есть стандартный набор скриптов, который выполняется при загрузке через PXE для всех. Как он тебе найдет ОС если загрузился через PXE. Ты можешь написать скрипт, который выполнится из под загруженной через PXE системой и выдаст тебе статус в MaaS или выполнит еще какие-нибудь действия.

Тут речь про то, что бы при загрузке в enlist проделать, всё те же операции но после этого не выключать хост (как это по дефолту), а продолжить загрузку уже с установленной ОС. Вот что я имел в виду.

Или править логику вышитых в MaaS скриптов.

Видимо остается этот вариант. Странно почему они не вынесли enlist как-то отдельно, чтоб можно было его модифицировать или добавлять какие то скрипты при первой инициализации. Я думал как раз что можно написать какой-то кастом слюда для первичной инициализации сюда etc/maas/preseeds/enlist.

Он не будет выключать, если ты галочку там поставишь при Commission. Можно кастомный скрипт подсунуть, а можно вшитый скрипт перекроить, они там в папочке лежат одной все. Или ты про инсталенную ОС не MaaSом?

Видимо остается этот вариант. Странно почему они не вынесли enlist как-то отдельно, чтоб можно было его модифицировать или добавлять какие то скрипты при первой инициализации. Я думал как раз что можно написать какой-то кастом слюда для первичной инициализации сюда etc/maas/preseeds/enlist.

Ага именно про ОС которая не через Maas поставлена была.

Пишешь testing scrypt, который проверяет на наличие ОС.

Можешь comission скрипт написать, но он будет выполнятся всегда и для всех.

Можешь написать скрипт проверки, что если он находит ОС, то загружается с нее, если нет, то выключается.

@Millagart а с генерацией имен ничего поделать нельзя? Хотелось бы свои автоматом генерить на основе lldp при первой инициализации. И как-то бы автоматом по зонам размещать сразу. Не делал ничего подобного?

@Millagart а с генерацией имен ничего поделать нельзя? Хотелось бы свои автоматом генерить на основе lldp при первой инициализации. И как-то бы автоматом по зонам размещать сразу. Не делал ничего подобного?

Интересно, какое ты иммя вытащишь по LLDP? Я бы сразу по IPMI тянул, если на то пошло.

А нова (ironic) позволяет кастомный hostname ставить 👀

Я прохо в опенстаках разбираюсь, сейчас вот еще с bifrost (ironic) немного копаю. Подскажи, Nova (ironic) можно юзать исключительно для деплоя ОС с минимальными изменениями в образе? Без агентов всяких внутри и т.д. Ну и с учетом, что у нас свои dhcp)

Я прохо в опенстаках разбираюсь, сейчас вот еще с bifrost (ironic) немного копаю. Подскажи, Nova (ironic) можно юзать исключительно для деплоя ОС с минимальными изменениями в образе? Без агентов всяких внутри и т.д. Ну и с учетом, что у нас свои dhcp)

nova можно прикрутить чтоб не возиться с самопальными средствами отдачи метаданных или с config drive.

там есть какой-то пул шаблонов под основных вендоров для этого?

там есть какой-то пул шаблонов под основных вендоров для этого?

Что конкретно ты имеешь ввиду под шаблонами?

Ну типа рейд собрать аппаратный на Dell или lenovo не используя OME и XClarity.

образы вам потребуется самому пилить в большинстве случаев

nova можно прикрутить чтоб не возиться с самопальными средствами отдачи метаданных или с config drive.

Чет я уже ничего не понимаю в этом OVN мире =) Invalid input for operation: physical_network 'physnet1' unknown for VLAN provider network. Neutron server returns request_ids: ['req-56fe7c6c-024a-4742-8d55-e68649ee6c14'] при этом (openvswitch-db)[root@kolla-cmp-02 /]# ovs-vsctl get Open_vSwitch . external_ids:ovn-bridge-mappings "physnet1:br-ex"

псс, бери тангстен

да не нужен мне тангстен =) пока уже точно

зачем тебе тогда овн ?)

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

Вопрос по openstack-kolla. Сейчас есть отдельные ноды под компьют, отдельные под контрол, если прописать контрол также и в компьют, как опенстек будет распределять ресурсы, можно ли жестко задать средствами openstack какое-то количество ресурсов под контрол, а какое то под компьют

Вопрос по openstack-kolla. Сейчас есть отдельные ноды под компьют, отдельные под контрол, если прописать контрол также и в компьют, как опенстек будет распределять ресурсы, можно ли жестко задать средствами openstack какое-то количество ресурсов под контрол, а какое то под компьют

Чет я уже ничего не понимаю в этом OVN мире =) Invalid input for operation: physical_network 'physnet1' unknown for VLAN provider network. Neutron server returns request_ids: ['req-56fe7c6c-024a-4742-8d55-e68649ee6c14'] при этом (openvswitch-db)[root@kolla-cmp-02 /]# ovs-vsctl get Open_vSwitch . external_ids:ovn-bridge-mappings "physnet1:br-ex"

А есть вообще понимание как OVN работает? Ну что есть там у него NorthDB, SouthDB которые где-то на контрольке вертятся? Просто то, что ты показываешь к компут ноды (могу предположить что это компут нода по названию хоста) - это же просто локальная ovs база данных. Синхронизация между "центром" и "переферией" есть вообще? Я так понял что ты на компут ноде руками (через ovs-vsctl set open. ) базу пополнял

в vars у нее все прописано .... нету вари и дпдк выключен, бери br-ex /opt/kolla/share/kolla-ansible/ansible/group_vars/all.yml:neutron_bridge_name: "{{ 'br-dvs' if neutron_plugin_agent == 'vmware_dvs' else 'br_dpdk' if enable_ovs_dpdk | bool else 'br-ex' }}"

Посмотрите в bootstrap таски по ovn, он там в зависимости от групп хостов прописывает ovn-bridge-mappings.

базу наполняла колла =) я потом немного говнишка принес.

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

ну вот как в базу NorthDB маппинг прописать, я не нашел

Ну а вот тут уже думать надо...проявлять так сказать то, что от нас требует мир опенстека. У тебя же вроде задача звучит как "порт маппинг, для будущего создания VLAN сеток"... Для меня это просто не понятно, что именно сделать хочешь. А судя по тому что пытался "physnet1:br-ex" указать - ты провайдерскую сеть хочешь куда-то запихать?

и камень предкновения здесь только связка neutron и ovn, с ML2 все было проще, сходил в конфиг написал и ты молодец

[Disclaimer] - Скорее всего всё, что я ниже напишу - ошибка, я не могу быть в этом уверен, так как опенсорс с неоднозначной (по крайней мере для меня) документаций. Всё описано так, как я это понимаю и если кто-то меня поправит - буду рад. [/Disclaimer] ML2 не исключает OVN, как и OVN не исключает ML2. OVN - это драйвер для ML2. Посему собственно то, что вы настраиваете в globals.yaml появится в том числе и в в ml2_conf.ini в конце концов (как минимум в виде mechanism_drivers = ovn) Если нужно "много вланов наружу" очевидно должен быть тот самый интерфейс "наружу" - этот интерфейс (если он один) определяется через neutron_external_interface (в globals.yaml). Дальше он будет забриджован OVS-ом в сущность br-ex (которая будет смаплена с physnet1). ВАЖНО то, что описано в предыдущем предложении будет сделано только на network нодах (то есть на нодах, которые помещены в группу network), однако часто требуется что-бы всё это было и на компут нодах, для этого надо что бы параметр "enable_neutron_provider_networks" был установлен в "yes" (в globals.yaml) На самом деле можно увидеть что пофигу какой агент используется - ovs ли, ovn ли, логика одна по факту. Дальше просто нарезайте вланы (важно следить что бы они попадали в рейндж [ml2_type_vlan] -> network_vlan_ranges Итого - kolla всё должна сделать красиво внезависимости ovs у вас или ovn - наконфиугурить *.ini файлы на нейтрон-сервере и наконфигурить базы данных ovs-а на компутах. Следите за переменными, следите что наконфигурилось в итоге в neutron.ini и ml2_conf.ini, следите за бриджами, проверьте на всех ли компутах пролились ovn-agent-ы (именно они локально ответственны за консистентность)

> Дальше он будет забриджован OVS-ом в сущность br-ex (которая будет смаплена с physnet1). Да, но опенстек так не считает, и это основная проблема.

root@kolla-service:~# openstack network create --project service --external --provider-network-type vlan --provider-physical-network physnet1 --provider-segment 104 External Проблема то вот =) Error while executing command: BadRequestException: 400, Invalid input for operation: physical_network 'physnet1' unknown for VLAN provider network.

А в итоге "ovs-vsctl list-ports br-ex" везде (на всех нодах) показыват ens19 в наличие?

А маппинг то в получившемся конфиге агента ты смотрел? Я чот не следил за развитием событий)

Ну и зря, как бы.

root@kolla-service:~# openstack network create --project service --external --provider-network-type vlan --provider-physical-network physnet1 --provider-segment 104 External Проблема то вот =) Error while executing command: BadRequestException: 400, Invalid input for operation: physical_network 'physnet1' unknown for VLAN provider network.