а ну да, у вас же не с нуля :) тогда да, хдист расковырять быстрее будет

но веселая магия хуков спалит тебе немало нервов :)

я уже на улицу осторожно так выхожу :)

а в автомэйшон чате обсуждают автоматизацию апи через постмэн блэт

Идея в чем. Когда то демонов было 10 и проблем не было.

Когда я переводил на пайтест я сделал в лоб.
Для каждого демона есть классы которые умеют его поднимать, поднимать его обвязку, настраивать конфиги натравливая демоны на обвязку, создавать ему базы, директории итд.
Так же для каждого демона тестовые данные (бд, кликхаус, что то на диске итд) должны лежать до того как он стартанет, поэтому у каждого теста есть метод prepare, и все эти методы от всех тестов вызываются до старта сессии и до запуска демонов.

Чтобы нормально дистрибьютить тесты а не тупыми пачками как это делает xdist я переписал планировщик и заставил чтобы на 1 воркере работал только 1 тест, а остальные раскидывались по мере освобождения воркеров.
Но это породило проблему, я не знал на какой воркер какой тест для какого демона придет.
Решение было очевидным, конфигурить и запускать копию каждого демона на каждом воркере со своими портами, базами и прочим и прогонять подготовку для всех тестов на каждом воркере.

Получалось, что у нас N воркеров по 10 сконфигуренных демонов на каждом и на каждом готовы тестовые данные для всех тестов, то есть куча копий, зато в любой момент любой тест прилетает на любой воркер и готов отработать. Да, потеряли на ресурсах чтобы все это было запущено одновременно и работало. Да, теряли время и ресуры на генерацию N копий данных. Зато было ахуительно распределение, которое перекрывало эти потери.

Но все хорошее когда нибудь заканчивается, демонов стало почти 30 и мы тупо упираемся в ресурсы тачки даже для 1 запуска.

Поэтому у меня возникла идея, чтобы не перепиливать логику конфигурации демонов и связку с тестами, перепилить планировщик более глобоко чем до этого. Самому решать какие демона с тестами на какой воркер должны прилететь в самом начале, далее каждый воркер поднимет только нужные демона и прогоняет подготовку только для нужных тестов. Плюс на это дело накинуть тайминги от предыдущих прогонов, чтобы добиться того самого распределения. Итого распределение должно будет быть плюс минус такое же, а ресурсов N на это в Nраз меньше.

и разное количество я уже раскидал, это не сложно, а вот как заставить теперь не падать все подряд, это пиздец

[gw0] Python 3.8.1 (default, Jan 23 2020, 14:31:30)  -- [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
[gw1] Python 3.8.1 (default, Jan 23 2020, 14:31:30)  -- [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
gw0 [26] / gw1 [18]

ага, логгирование там супер :)

INTERNALERROR> OSError: cannot send to <Channel id=3 closed>

INTERNALERROR> RuntimeError: Unexpectedly no active workers available

заебло слегка)

беда в том что этот DSession нормально не отнаследуешь

если планировщик изи, то это просто дичь какая то

это да, но рано или поздно вылазить за хдист придется. ибо внешним кодом это все делается очень просто. Я собираю список тестов на запуск (по переданным маркам), и сразу вижу, скольким тестам нужны какие прекондишены(читай твои демоны и сеты данных). Из этого я могу соорудить нужное число воркеров с нужным числом прекондишенов, ну плюс учитывать тайминги тестов(на текущем месте пока нет, тут пока еще все активно меняется в плане длительности). Ну и дальше кидать тесты туда, где для них прекондишены засетаплены

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

а как потом мапить прекондишены в тест? ну то есть мне прекондишены нужны чтобы потом по ним запрашивать инфу

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

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

в общем это сейчас так удобно сделано что тупо жалко переделывать, а проблему с ресурсами решать надо

можно тупо планировщиком разрулить и еще чутка поговнокодить, но хочется К Р А С И В О

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

а, мля тут просто