J
Вроде, так выходит)
J
Угу, часто про это думаю.
icewolf
украду картинку
icewolf
я в этих молодежных сленгах не Копенгаген
John
Есть ещё?
Mr
А boost не поможет. Там же проблема гораздо уже, только когда начинаешь пользоваться понимаешь что у тебя почему то скорость интерфейса не соответствует заявленным характеристикам.. и этот шарик почему то начинает становится не правильной формы, напоминающих известное изделие фирмы vizit
Только у экономных. https://www.microsoft.com/en-us/research/project/azure-smartnic/
Mr
icewolf
32 гбита с smart nic, мало ?
Майки за рекламу доплачивают? Или все так хорошо у майков с Intel? а может все очень хорошо на Linux инстансах?
icewolf
Только у экономных. https://www.microsoft.com/en-us/research/project/azure-smartnic/
страшный сон для всех кто так или иначе использовал эти аксилярационные технологии, с потерей пакетов.
icewolf
суть в том что это на сетевушках AMD, и работает это на Azure только в связке с windows server. Но слой технологий не ограничивается только виндой, как правило там и linux внезапно нужен и аплаенсы вендоров, которые немного не работают так как заявлено.
Artemy
Несколько раз слышал что некоторые вместо выбора AZ дают конечным пользователям наборы флейворов к агрегатам привязанные.
И я как-то до конца не могу понять какие плюсы у этой схемы)
Я знаю одно облако которое вместо типа волюма плюс зона доступности выдумало по отдельному типу для каждой зоны, затем устроили вокруг этого приседания в вебморде и еще поимели кучу боли. А все потому, что не было знаний и опыта
Artemy
icewolf
Ilya
Коллеги, подскажите пожалуйста. При создании инстанса какой порядок действий? Сначала scheduler,потом устанавливается на compute,а потом подтягивается нейтрон?
Вот базовые вещи приблизительно так выглядят:
Ilya
Ilya
Тектстовое описание части 1:
1.User logs in to Horizon GUI, specifies VM parameters (Name, flavor, etc.) and hits the Create button. Horizon sends HTTP request to Keystone.
2.Keystone parses HTTP request and verifies that the credentials are valid (Authentication), User-to-Tenant-Role mapping is valid (Access Control) and the requested action is available for this user (Authorization).
3.Keystone sends temporary token back to Horizon via HTTP.
4.Horizon sends POST request to Nova API (signed with given token) to boot a VM.
5.Nova API sends HTTP request to Validate API token to Keystone.
6.Keystone validates API token.
7.Keystone sends HTTP response with token acceptance/rejection info.
8.Nova API parses request to Python object model and validates it by fetching data from Nova DB. If request is valid, it saves initial db entry about VM to the database.
9.Nova API makes RPC-cast call to nova-scheduler. It publishes a short message to scheduler queue with VM info.
10.Nova-scheduler picks up the message from message queue.
11.Nova-scheduler fetches information about the whole cluster from database, filters, and selects compute node and updates DB with its ID.
12.Nova-scheduler publishes message to the compute queue (based on host ID) to trigger VM provisioning.
13.Nova-compute gets message from message queue.
Ilya
Ilya
Тектстовое описание части 2:
14.Nova-compute makes RPC call to nova-conductor for information on VM from database (DB).
15.Nova-conductor extracts message from queue, and queries Nova DB.
16.It then responds by sending VM info to nova-compute.
17.Nova-compute makes a call to Neutron API to provision network for the instance. It also sends an authentication token.
18.Neutron checks the token with the keystone-api.
19.Neutron configures IP, gateway, DNS name, L2 connectivity, etc. for the VM.
20.Neutron responds to nova-compute with network settings.
21.Nova-compute contacts Cinder to get volume data. Here it is assumed that a volume is already created. Nova can also attach volumes after VM is built. At this point Nova-compute also sets up iSCSI initiator and instructs the Hypervisor to mount iSCSI volume as a new block device.
22.Nova-compute requests VM image from Glance using image ID obtained previously.
23.Glance checks the token with keystone-api.
24.Glane checks for the requested image data.
25.If image with given image ID can be found, URI is returned. Then, Nova-compute downloads image using HTTP Get URI, given by Glance, from Swift (or Glance’s back-end) - note this action is not shown on the slide.
26.Nova Compute fetches information about VM from DB (through Nova-conductor), creates a command to Hypervisor and delegates VM rendering to Hypervisor.
27.Finally, Nova-compute sends a message to Nova-conductor to update DB with VM state.
John
Спасибо
Ilya
В районе п.11 еще плейсмент дёргается... Видимо когда дока писалась, его еще не вытащили в отдельное АПИ
J
Тектстовое описание части 1:
1.User logs in to Horizon GUI, specifies VM parameters (Name, flavor, etc.) and hits the Create button. Horizon sends HTTP request to Keystone.
2.Keystone parses HTTP request and verifies that the credentials are valid (Authentication), User-to-Tenant-Role mapping is valid (Access Control) and the requested action is available for this user (Authorization).
3.Keystone sends temporary token back to Horizon via HTTP.
4.Horizon sends POST request to Nova API (signed with given token) to boot a VM.
5.Nova API sends HTTP request to Validate API token to Keystone.
6.Keystone validates API token.
7.Keystone sends HTTP response with token acceptance/rejection info.
8.Nova API parses request to Python object model and validates it by fetching data from Nova DB. If request is valid, it saves initial db entry about VM to the database.
9.Nova API makes RPC-cast call to nova-scheduler. It publishes a short message to scheduler queue with VM info.
10.Nova-scheduler picks up the message from message queue.
11.Nova-scheduler fetches information about the whole cluster from database, filters, and selects compute node and updates DB with its ID.
12.Nova-scheduler publishes message to the compute queue (based on host ID) to trigger VM provisioning.
13.Nova-compute gets message from message queue.
Это ж старое немножко.
Напрямую теперь nova-api и scheduler не общаются, всё через conductor. И в схеме нет placement, зато жунипер подробнейше зачем-то про horizon и keystone расписали)
Ilya
Получается типа этого часть 1. Уже не соответствует картинке:
1.User logs in to Horizon GUI, specifies VM parameters (Name, flavor, etc.) and hits the Create button. Horizon sends HTTP request to Keystone.
2.Keystone parses HTTP request and verifies that the credentials are valid (Authentication), User-to-Tenant-Role mapping is valid (Access Control) and the requested action is available for this user (Authorization).
3.Keystone sends temporary token back to Horizon via HTTP.
4.Horizon sends POST request to Nova API (signed with given token) to boot a VM.
5.Nova API sends HTTP request to Validate API token to Keystone.
6.Keystone validates API token.
7.Keystone sends HTTP response with token acceptance/rejection info.
8.Nova API parses request to Python object model and validates it by fetching data from Nova DB. If request is valid, it saves initial db entry about VM to the database.
9.Nova API makes RPC-cast call to nova-conductor. It publishes a short message to conductor queue with VM info.
10.Nova-conductor picks up the message from message queue.
11.Nova-conductor makes RPC-cast call to nova-scheduler
11.5 Nova-scheduler picks up the message from message queue. fetches information about the whole cluster from database, filters, and selects compute node candidates.
11.6 Nova-scheduler makes REST API calls to placement to check available resources and put allocations.
11.7 Nova-scheduler returns result with selected hosts via RPC message to conductor
12.Nova-conductor publishes message to the compute queue (based on host ID) to trigger VM provisioning.
13.Nova-compute gets message from message queue.
J
А, проглядел)
J
Сначала запрашивает у плейсмента кандидатов с подходящим набором ресурсов, а потом уже фильтрует, а у тебя наоборот получается.
icewolf
Меня 11.5 смутил, он неправильный.
Не смущайтесь это дока у Ильи вроде от контрейла, и там версия явно qweens
Ilya
Сначала запрашивает у плейсмента кандидатов с подходящим набором ресурсов, а потом уже фильтрует, а у тебя наоборот получается.
Судя по исходному коду и логам это происходит так:
2024-08-25 13:37:30.580 7 DEBUG nova.scheduler.manager [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Starting to schedule for instances: ['b22d80fa-bd2e-49ce-a03f-e5ec1ddedfa8'] select_destinations /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/manager.py:141
....
2024-08-25 13:37:30.682 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Starting with 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:69
...
2024-08-25 13:37:30.685 7 DEBUG nova.scheduler.utils [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Attempting to claim resources in the placement API for instance b22d80fa-bd2e-49ce-a03f-e5ec1ddedfa8 claim_resources /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/utils.py:1244
```
icewolf
Кстати Илья, поделитесь учебным материалом от juniper по контролейлу. У меня скоро отпуск(14 сентября) буду читать на море
icewolf
icewolf
Вот этой👇🏻
icewolf
icewolf
она очень редкая обучающая дока, по контрейлу
J
Судя по исходному коду и логам это происходит так:
2024-08-25 13:37:30.580 7 DEBUG nova.scheduler.manager [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Starting to schedule for instances: ['b22d80fa-bd2e-49ce-a03f-e5ec1ddedfa8'] select_destinations /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/manager.py:141
....
2024-08-25 13:37:30.682 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Starting with 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:69
...
2024-08-25 13:37:30.685 7 DEBUG nova.scheduler.utils [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Attempting to claim resources in the placement API for instance b22d80fa-bd2e-49ce-a03f-e5ec1ddedfa8 claim_resources /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/utils.py:1244
```
Я тебе не нашел свежую доку, к сожалению, но вот как раз в пайке схема поменялась.
https://docs.openstack.org/nova/queens/user/placement.html#pike-16-0-0
Ilya
Aleksandr
Кстати Илья, поделитесь учебным материалом от juniper по контролейлу. У меня скоро отпуск(14 сентября) буду читать на море
ты там не в Сочи на Микроэлектронику собрался ?)
Aleksandr
а то дата подозрительная )
icewolf
ты там не в Сочи на Микроэлектронику собрался ?)
Близко, скажем так это конечная точка от новой трассы
Ilya
Я смотрю на тестовый стенд на зине
А с плейсментом мне интересно - буду подробнее смотреть, но позже. Согласен - выглядит не очень красиво, меня это удивило...
icewolf
А с плейсментом мне интересно - буду подробнее смотреть, но позже. Согласен - выглядит не очень красиво, меня это удивило...
в доке у вас указан 2017 год, значит там контрейл или 2014 или около того а он был на pike или qweens не помню, но на чем то таком
icewolf
на самом деле я эту доку в бумажном виде пролюбил.. так то с картинками она у меня тоже была прям бумажная
Ilya
в доке у вас указан 2017 год, значит там контрейл или 2014 или около того а он был на pike или qweens не помню, но на чем то таком
я смотрю на тангстен плюс зина, а доки старые, это да. Свежее не будет насколько я знаю. Только если я сам и буду писать ...
icewolf
Да я даже старой доке рад. Как бы это сказать ручки потренировать
icewolf
а так можете скинуть старую доку в лс, тем более вы в белом списке(что случайность для этого чата)
icewolf
а то дата подозрительная )
А в чем подозрительность? 13 сентября в 10:30 двухэтажным поездом, до станции Горячий ключ, далее на трансфере до парк отеля
Aleksandr
А в чем подозрительность? 13 сентября в 10:30 двухэтажным поездом, до станции Горячий ключ, далее на трансфере до парк отеля
тем что форум в это время )) думал мо ж ты тудой заодно ) мы то с ГЮ полюбаш шашлык машлык будем )
icewolf
J
А с плейсментом мне интересно - буду подробнее смотреть, но позже. Согласен - выглядит не очень красиво, меня это удивило...
Нашел еще в закладках у себя)
https://docs.openstack.org/nova/latest/reference/scheduling.html
Чуть погодя попробую логи найти)
J
@ipo78
Смотри)
https://opendev.org/openstack/nova/src/commit/6fadd9980d53d7d93852d0622974bcf5c9a4a19f/nova/scheduler/manager.py#L114
В select destinations нихрена нет никакого логировани кроме двух случаев :
1. Если placement не вернул никаких кандидатов
2. Если включен фоллбек для выделения запиненных ядер. Тогда вторым запросом шедулер себя страхует и запрашивает кандидатов с vCPU, а не с pCPU и об этом пишет в лог.
А при нормальной работе ничего. Поэтому в логе шедулера толком и не увидишь.
А вот в логе placement будет видно прям запрос от шедулера, типа вот такого:
2024-08-25 15:57:57.834 1510046 INFO placement.requestlog [req-6b87c056-b9de-40cb-ae91-a1cd0fc913e2 5564b7b97c204c2a83b333ef000936a0 c253a50902504b05b2dade856b555552 - default default] "GET /allocation_candidates?limit=1000&member_of=%21in%3A4ecc0fd1-1e79-42b7-a135-cdf194d02db0%2C91254921-f893-47cb-81d7-6db7a5723cf8%2Cf1734a85-7fb5-42b2-8071-33077e9faf69&resources=DISK_GB%3A20%2CMEMORY_MB%3A4096%2CVCPU%3A2&root_required=%21COMPUTE_STATUS_DISABLED" status: 200 len: 252005 microversion: 1.36
icewolf
Тем временем Павел Дуров уже 1 день в тюрьме
Ilya
@ipo78
Смотри)
https://opendev.org/openstack/nova/src/commit/6fadd9980d53d7d93852d0622974bcf5c9a4a19f/nova/scheduler/manager.py#L114
В select destinations нихрена нет никакого логировани кроме двух случаев :
1. Если placement не вернул никаких кандидатов
2. Если включен фоллбек для выделения запиненных ядер. Тогда вторым запросом шедулер себя страхует и запрашивает кандидатов с vCPU, а не с pCPU и об этом пишет в лог.
А при нормальной работе ничего. Поэтому в логе шедулера толком и не увидишь.
А вот в логе placement будет видно прям запрос от шедулера, типа вот такого:
2024-08-25 15:57:57.834 1510046 INFO placement.requestlog [req-6b87c056-b9de-40cb-ae91-a1cd0fc913e2 5564b7b97c204c2a83b333ef000936a0 c253a50902504b05b2dade856b555552 - default default] "GET /allocation_candidates?limit=1000&member_of=%21in%3A4ecc0fd1-1e79-42b7-a135-cdf194d02db0%2C91254921-f893-47cb-81d7-6db7a5723cf8%2Cf1734a85-7fb5-42b2-8071-33077e9faf69&resources=DISK_GB%3A20%2CMEMORY_MB%3A4096%2CVCPU%3A2&root_required=%21COMPUTE_STATUS_DISABLED" status: 200 len: 252005 microversion: 1.36
Да, всё так. Просто в логе до обращения к плейсменту видно, что шедулер пробегает по всем фильтрам. Плейсмент про фильтры шедулера ничего не знает...Поэтому вполне логично, что шедулер выбирает список гиперов по фильтрам и взвешивателям, а потом идёт в плейсмент. Скорее всего множества после фильтрации шедулера и то что вернул плейсмент пересекаются
Ilya
И результат используется кондактором, как основной и альтернативный кандидаты.
J
Да, всё так. Просто в логе до обращения к плейсменту видно, что шедулер пробегает по всем фильтрам. Плейсмент про фильтры шедулера ничего не знает...Поэтому вполне логично, что шедулер выбирает список гиперов по фильтрам и взвешивателям, а потом идёт в плейсмент. Скорее всего множества после фильтрации шедулера и то что вернул плейсмент пересекаются
Ты повторяешь то же что выше писал уже)
Плейсменту не нужно знать, он работает с ресурс классами ресурс провайдеров.
Давай еще разок повторю)
1. Шедулер у плейсмента запрашивает список ресурс провайдеров где есть соответствующее флейвору количество ресурсов.
2. Плейсмент возвращает кандидатов
3. Шедулер прогоняет список кандидатов через фильтры и выбирает в итоге куда пихнуть вм.
J
Ты повторяешь то же что выше писал уже)
Плейсменту не нужно знать, он работает с ресурс классами ресурс провайдеров.
Давай еще разок повторю)
1. Шедулер у плейсмента запрашивает список ресурс провайдеров где есть соответствующее флейвору количество ресурсов.
2. Плейсмент возвращает кандидатов
3. Шедулер прогоняет список кандидатов через фильтры и выбирает в итоге куда пихнуть вм.
То есть, это не два паралелльных процесса:
Запрос у плейсмента кандидатов и фильтрация в шедулере.
Это последовательность. Сначала список кандидатов, потом прогон их через фильтры.
Этот процесс двухступенчатый как раз потому что плейсмент не умеет работать с более сложными абстракциями типа экстра спек агрегейтов, весов каждого ресурса или еще чего.
icewolf
плейсмент нужен как я понял для сервиса watcher.. ну может ошибаюсь но там именно DRS
J
плейсмент нужен как я понял для сервиса watcher.. ну может ошибаюсь но там именно DRS
Плейсмент нужен потому что команда nova не захотела возиться дальше с учетом ресурсов и предпочла спихнуть его в отдельный сервис.
Это разумно, но немножко усложнило процесс шедулинга. Но одновременно и ускорило. Потому что раньше nova-scheduler тупо ваще все хосты прогонял через набор фильтров.
Ilya
Ты повторяешь то же что выше писал уже)
Плейсменту не нужно знать, он работает с ресурс классами ресурс провайдеров.
Давай еще разок повторю)
1. Шедулер у плейсмента запрашивает список ресурс провайдеров где есть соответствующее флейвору количество ресурсов.
2. Плейсмент возвращает кандидатов
3. Шедулер прогоняет список кандидатов через фильтры и выбирает в итоге куда пихнуть вм.
Вот что видно в логах шедулера у меня:
2024-08-25 13:37:30.580 7 DEBUG nova.scheduler.manager [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Starting to schedule for instances: ['b22d80fa-bd2e-49ce-a03f-e5ec1ddedfa8'] select_destinations /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/manager.py:141
2024-08-25 13:37:30.581 7 DEBUG nova.scheduler.request_filter [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] compute_status_filter request filter added forbidden trait COMPUTE_STATUS_DISABLED compute_status_filter /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/request_filter.py:252
2024-08-25 13:37:30.581 7 DEBUG nova.scheduler.request_filter [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Request filter 'compute_status_filter' took 0.0 seconds wrapper /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/request_filter.py:46
2024-08-25 13:37:30.581 7 DEBUG nova.scheduler.request_filter [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Request filter 'accelerators_filter' took 0.0 seconds wrapper /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/request_filter.py:46
....
2024-08-25 13:37:30.682 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Starting with 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:69
2024-08-25 13:37:30.683 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Filter ComputeFilter returned 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:101
2024-08-25 13:37:30.683 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Filter ComputeCapabilitiesFilter returned 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:101
2024-08-25 13:37:30.683 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Filter ImagePropertiesFilter returned 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:101
2024-08-25 13:37:30.684 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Filter ServerGroupAntiAffinityFilter returned 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:101
2024-08-25 13:37:30.684 7 DEBUG nova.filters [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Filter ServerGroupAffinityFilter returned 3 host(s) get_filtered_objects /var/lib/kolla/venv/lib/python3.8/site-packages/nova/filters.py:101
2024-08-25 13:37:30.684 7 DEBUG nova.scheduler.manager [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Filtered [(compute0.stage-latest, compute0.stage-latest) ram: 7393MB disk: 40960MB io_ops: 0 instances: 1, (compute2.stage-latest, compute2.stage-latest) ram: 8417MB disk: 40960MB io_ops: 0 instances: 0, (compute1.stage-latest, compute1.stage-latest) ram: 7393MB disk: 40960MB io_ops: 0 instances: 1] _get_sorted_hosts /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/manager.py:610
Ilya
Ты повторяешь то же что выше писал уже)
Плейсменту не нужно знать, он работает с ресурс классами ресурс провайдеров.
Давай еще разок повторю)
1. Шедулер у плейсмента запрашивает список ресурс провайдеров где есть соответствующее флейвору количество ресурсов.
2. Плейсмент возвращает кандидатов
3. Шедулер прогоняет список кандидатов через фильтры и выбирает в итоге куда пихнуть вм.
2024-08-25 13:37:30.685 7 DEBUG nova.scheduler.manager [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Weighed [WeighedHost [host: (compute2.stage-latest, compute2.stage-latest) ram: 8417MB disk: 40960MB io_ops: 0 instances: 0, weight: 3.0], WeighedHost [host: (compute0.stage-latest, compute0.stage-latest) ram: 7393MB disk: 40960MB io_ops: 0 instances: 1, weight: 2.8627164518236903], WeighedHost [host: (compute1.stage-latest, compute1.stage-latest) ram: 7393MB disk: 40960MB io_ops: 0 instances: 1, weight: 2.8627164518236903]] _get_sorted_hosts /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/manager.py:632
2024-08-25 13:37:30.685 7 DEBUG nova.scheduler.utils [req-1f93ec56-33d7-4bf0-81e1-29ae15ed5bbb 1a91d75bb86d41b9896809f16d629e66 a3183086f2b44cf3a731a169297e4309 - default default] Attempting to claim resources in the placement API for instance b22d80fa-bd2e-49ce-a03f-e5ec1ddedfa8 claim_resources /var/lib/kolla/venv/lib/python3.8/site-packages/nova/scheduler/utils.py:1244
Ilya
А вот гже фильры дёргаются (еще до плейсмента):
https://opendev.org/openstack/nova/src/commit/6fadd9980d53d7d93852d0622974bcf5c9a4a19f/nova/scheduler/manager.py#L154
Ilya
Есть вариант, что где то есть еще обращение в плейсмент до фильтров, но я пока не нашёл...
J
А вот гже фильры дёргаются (еще до плейсмента):
https://opendev.org/openstack/nova/src/commit/6fadd9980d53d7d93852d0622974bcf5c9a4a19f/nova/scheduler/manager.py#L154
Эт не полноценные фильтры, это так называемые префильтры же.
Ilya
Эт не полноценные фильтры, это так называемые префильтры же.
Да, это префильтры. Их в логе видно. Потом идут классические фильтры. А потом уже обращение в плейсмент... Буду дальше копать
Ilya
Но уже не сегодня
J
А вот гже фильры дёргаются (еще до плейсмента):
https://opendev.org/openstack/nova/src/commit/6fadd9980d53d7d93852d0622974bcf5c9a4a19f/nova/scheduler/manager.py#L154
Вот их список.
https://opendev.org/openstack/nova/src/commit/6fadd9980d53d7d93852d0622974bcf5c9a4a19f/nova/scheduler/request_filter.py#L368
А вот сам метод.
https://opendev.org/openstack/nova/src/commit/6fadd9980d53d7d93852d0622974bcf5c9a4a19f/nova/scheduler/request_filter.py#L380
J
Да, это префильтры. Их в логе видно. Потом идут классические фильтры. А потом уже обращение в плейсмент... Буду дальше копать
Ты же сам код скинул, как раз нужное место)
Сразу после прогонки реквест спеки через префильтры из неё формируется запрос ресурсов и отправляется в плейсмент.
Ilya
Ты же сам код скинул, как раз нужное место)
Сразу после прогонки реквест спеки через префильтры из неё формируется запрос ресурсов и отправляется в плейсмент.
Угу, если потом прогоняем фильтры, а потом идём в плейсмен ресурсы занимать, то выглядит логично... Тогда то сообщение, что после фильтров - это уже второе обращение в плейсмент
Ilya
А первое не логировалось
J
Угу, если потом прогоняем фильтры, а потом идём в плейсмен ресурсы занимать, то выглядит логично... Тогда то сообщение, что после фильтров - это уже второе обращение в плейсмент
Ага, так и есть.
Плейсмент вместе со списком ресурс провайдеров сразу возвращает аллокейшн реквесты. Шедулеру даже не надо их формировать)
Он берет готовый аллокейшн реквест, который ему плейсмент вернул в первый запрос и с этим реквестом как раз и лезет занимать ресурсы.
И вот этот момент логируется.
J
Ага, так и есть.
Плейсмент вместе со списком ресурс провайдеров сразу возвращает аллокейшн реквесты. Шедулеру даже не надо их формировать)
Он берет готовый аллокейшн реквест, который ему плейсмент вернул в первый запрос и с этим реквестом как раз и лезет занимать ресурсы.
И вот этот момент логируется.
https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/placement-allocation-requests.html
Ilya
Ага, так и есть.
Плейсмент вместе со списком ресурс провайдеров сразу возвращает аллокейшн реквесты. Шедулеру даже не надо их формировать)
Он берет готовый аллокейшн реквест, который ему плейсмент вернул в первый запрос и с этим реквестом как раз и лезет занимать ресурсы.
И вот этот момент логируется.
Спасибо, теперь выглядит более логично, буду более детально код смотреть.
J
Спасибо, теперь выглядит более логично, буду более детально код смотреть.
Заодно чутка и сам вспомнил и ссылки в одном месте собрал чтоб если что своим ребятам показывать)