Rolling update fixture #18430
Rolling update fixture #18430
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for rolling updates in the compatibility tests by introducing a new fixture and test, and ensures that updated binaries are picked up when restarting cluster nodes.
- Added a
binary_pathsetter and pre-start command update inKiKiMRNode - Introduced
RollingUpdateFixturein compatibility fixtures to drive rolling updates - Added a new
test_rolling.pyand included it in the compatibility test suite
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| ydb/tests/library/harness/kikimr_runner.py | Add binary_path setter and call update_command before node start |
| ydb/tests/library/compatibility/fixtures.py | Add RollingUpdateFixture with setup_cluster and roll methods |
| ydb/tests/compatibility/ya.make | Register test_rolling.py in the compatibility test targets |
| ydb/tests/compatibility/test_rolling.py | New rolling update test using the RollingUpdateFixture |
Comments suppressed due to low confidence (1)
ydb/tests/library/compatibility/fixtures.py:117
last_stable_binary_pathis not defined or imported in this module, causing a NameError. Please import it or define it before use.
self.all_binary_paths = [last_stable_binary_path]
| binary_paths=self.all_binary_p | ||
| aths, |
There was a problem hiding this comment.
The binary_paths argument is split across two lines resulting in invalid syntax. It should be a single identifier, e.g.: binary_paths=self.all_binary_paths,
| binary_paths=self.all_binary_p | |
| aths, | |
| binary_paths=self.all_binary_paths, |
|
🟢 |
|
⚪ Test history | Ya make output | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
|
⚪ Test history | Ya make output | Test bloat
⚪ Test history | Ya make output | Test bloat | Test bloat
⚪ Test history | Ya make output | Test bloat | Test bloat | Test bloat
🟢
*please be aware that the difference is based on comparing your commit and the last completed build from the post-commit, check comparation |
|
|
||
| for _ in self.roll(): | ||
| time.sleep(5) | ||
|
|
There was a problem hiding this comment.
я бы после roll предложил выполнить команды run, чтобы проверить что 1) таблицы не пропали 2) что все еще все работает
There was a problem hiding this comment.
Так run выполняется бесконечно пока кластер обновляется. + тут есть холостая итерация (см последний yield в реализации roll)
There was a problem hiding this comment.
не понял =( т.е тест выглядит так?
- запускаемся на версии A
- init + run
- rolling update на версию B, потом обратно на версию A?
| yield | ||
| self.cluster.stop() | ||
|
|
||
| def roll(self): |
There was a problem hiding this comment.
если честно не понял механику: этот метод делает обновление два раза? сначала на новый потом на старый?
There was a problem hiding this comment.
Да. Типа сначала накат, потом откат. У меня есть дока с пояснениями, я ее выложу как текущий ПР волью
There was a problem hiding this comment.
имхо это отличается от дефолтного понимания метода rolling_update. он должен как будто только с версии A на версию B переходить, а не откатывать потом еще обратно,
Это выглядит как другой сценарий/ класст тестов
There was a problem hiding this comment.
Давай назову
RollingUpgradeAndDowngradeFixture
-- кажется действительно более корректно
Норм?
2 participants
This PR adds support for rolling updates in the compatibility tests by introducing a new fixture and test, and ensures that updated binaries are picked up when restarting cluster nodes.