Re: [Tarantool-patches] [PATCH v1 0/4] test: stabilize testing with issue #5141

["Alexander V. Tikhonov" <avtikhon@tarantool.org>]

Никита, привет. Да у нас есть проблема от этого теста почти во всех
винильных тестах использующих box.snapshot. Включать и выключать тесты,
как мне кажется, это совсем крайний случай, поэтому мы попытались хоть
как-то изолировать проблему, но чтобы проблема продолжала
идентифицироваться был заведён тест полностью копирующий те части
тестов, что её обнаруживали, без каких-либо изменений. Да, то что есть
минимальный репродьюсер, это отлично, и то что тесты требуют правок
сомнений нет. Но с нашей стороны сейчас основная задача это
стабилизировать тестирование не растеряв найденые проблемы. Поэтому
предлагаю сейчас не пытаться найти новый путь решения проблемы, а
реально зафиксироваться на текущем состоянии, так как и тестирование
стабилизировано и тесты выявляют найденную проблему. В рамках правок
билета 5436 тесты явно будут исправляться и нет смысла с нашей стороны
предлагать свои решения для этого раньше, чем билет будет исправлен.

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

On Sun, Nov 01, 2020 at 09:57:35PM +0000, Nikita Pettik wrote:
> On 30 Oct 09:59, Alexander V. Tikhonov wrote:
> > To stabilize testing with issue #5141 the following steps had to be
> > done:
> 
> Сорри что влезаю, но что тут происходит? Парни, если тест сломан,
> его надо нормально починить, а не костылить слипами и тд. Там есть
> одна явная бага (5436), ей надо заняться. Я просто вижу какое-то насилование
> винильных тестов, это по-другому и не назовешь. Если надо срочно починить CI -
> просто отрубите этот тест (с апсертами) и все. Я постараюсь им заняться в
> ближайшее (и видимо свободное) время.
>  
> > - Prepare tests - add test-run filter on box.snapshot error message:
> > 
> >     'Invalid VYLOG file: Slice [0-9]+ deleted but not registered'
> > 
> >   to avoid of printing changing data in results file to be able to use
> >   its checksums in fragile list of test-run to rerun it as flaky issue.
> > 
> > - Create the stable reproducer for the issue #5141 as new standalone
> >   test vinyl/gh-5141-invalid-vylog-file.test.lua.
> 
> А зачем репродюсер тут? Я же уже и так открыл 5436 и вынес минимальный
> репро туда.
>