Pull to refresh
47
0
Сергей Бронников @estet

Пользователь

Send message

Проблема же может случиться между любыми двумя строчками, а если говорим о многопоточке - то от сочетания сайдэффектов/рассинхрона между множеством потоков.

В Tarantool есть несколько потоков, каждый из них занимается своей задачей: поток для обработки транзакций, поток для работы с запросами из сети, поток для работы с WAL. (подробнее про архитектуру в этой статье). Если мы, например, добавляем сбой для журнала (WAL), то это повлияет только на работу потока, который работает с WAL.

Поэтому в этом плане поведение детерминированное.

Есть ли Jepsen/Ducktape-like что-то в проекте?

Jepsen - да. Цитирую статью: "В 2020 году мы добавили поддержку синхронной репликации и MVCC. Появился запрос на тестирование этой функциональности и мы решили часть тестов сделать на основе фреймворка Jepsen. Консистентность проверяем с помощью анализа истории транзакций. Но рассказ про тестирование с помощью Jepsen вполне потянет на отдельную статью, поэтому об этом в следующий раз.".

Про Ducktape-like не понял, что имеется ввиду.

В целом вы правильно поняли это работает :)

видимо это настраивается на CI, так как по дефолту - false.

Обычно, да, все сбои выключены, включаются при необходимости в самом тесте.

Так все-же, что на картинке?

Пример кода, который добавляет новый сбой в код Тарантула.

Кто и как вносит изменения в код, и когда?

Автор патча может добавить новый сбой тогда, когда посчитает нужным.

Если посмотрите на пример такого патча, то думаю все вопросы отпадут - https://github.com/tarantool/tarantool/commit/a82ec30466

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

Реализация сбоев всегда в коде основной ветки проекта.

Привет, правильно я понял что error injections реализован через гитовые патчи кода?

Не понял, что такое гитовые патчи.

Если да, то почему не через тестовые имплементации интерфейсов (если это применимо для LUA)?

Наверное потому, что так было проще сделать. То, что вы описываете используется в SQLite, там есть набор вызовов, которые нужны библиотеке от ОС и легко можно реализацию менять на свою, см. https://www.sqlite.org/vfs.html.

Или, скажем, не через через фреймворки врапперы диска и прочих систем (как например сделано в Кафке - https://cwiki.apache.org/confluence/display/KAFKA/Fault+Injection)?

Обычно используют два подхода для внедрения сбоев: со стороны приложения и со стороны тестового окружения. У обоих подходов есть как плюсы так и минусы.

Для внедрения сбоев со стороны приложения большой плюс в простоте реализации, но есть минус - мы меняем код приложения и тем самым тестируем не тот код, который пойдёт в релиз. Есть даже специальные библиотеки для внедрения сбоев на уровне приложения - например https://github.com/pingcap/failpoint или https://github.com/albertito/libfiu. Соответственно для внедрения сбоев со стороны тестового окружения минус в том, что надо каким-то образом проксировать функции ОС, которые использует приложение (например сделать специальную ФС, использовать LD_PRELOAD и т.к.).

Вопрос - насколько реально легко использовать вещи вроде Coq для доказательства отсутствия дедлоков? Или это вообще не из той степи?

Если кратко, то нелегко. Доказать отсутствие дедлоков с помощью Coq можно. Но, наверное, более сложный вопрос не в том, можно верифицировать или нет, а в том, как связать верификацию и конкретную реализацию. Один из способов это сделать экстракцию формально верифицированного кода из Coq в OCaml или Haskell и интегрировать в основной проект.

Даже не все московские провайдеры внедряют IPv6. Несколько лет назад разговаривал с QWERTY насчёт использования IPv6 для клиентского оборудования и они даже не планировали ничего делать. И сейчас ничего не поменялось.

Провайдеры, которые поддерживают - https://version6.ru/isp.

Отличная статья!

Помню, как мы смеялись ещё раньше над сановскими кодами ошибок про космическое излучение, но вот пригодились же.

А расскажите про это подробнее.

Возможно стоит сайт по аналогии с http://no-color.org/ и добавлять туда программы, которые поддерживают отключение телеметрии.

Спасибо за перевод!

По своему опыту могу сказать, что статические проверки кода удобно делать с помощью semgrep. У меня есть примеры для go и python.

Зачем в текстовом формате? Можно и в графическом сравнивать.
Например с помощью KiCad-Diff

image

git diff можно настроить, чтобы использовать сторонние утилиты для сравнения файлов. см документацию
Возможно достаточно будет ptrace(2), который используется в gdb.
Спасибо за доклад и расшифровку в частности!

Вопрос: Следующий вопрос от Сергея Новикова: «Планов на wraparound случайно нет? Или цель инструмента все-таки проверка работы приложения и автоматики при аварии, а не тренировка DBA?».

Ответ: Wraparound довольно сложно сэмулировать — нужно писать (обновлять) много данных в течение долгого времени, то есть тест для воспроизведение получится очень продолжительный. Поэтому очень маловероятно что такой сценарий появится.


Проблему с wraparound можно воспроизвести перезаписав счетчик транзакций напрямую в памяти.
В PostgresPro делали исправление для проблемы с wraparound и мы тогда тестировали этот фикс.
Дима Васильев написал про это в отдельном посте — habr.com/ru/company/postgrespro/blog/301238
Всё это благолепие с разноцветным выводом нравится далеко не всем пользователям, поэтому имеет смысл предусмотреть отключение раскрашивания вывода.

no-color.org
скриншоте Manual page от git — супер-популярная, хорошая, и между прочим, очень продуманная программа. Manual page позволяет скроллить вывод вверх-вниз


Нет такой программы «Manual page», а есть программы, которые рендерят файл в формате mdoc: groff и его современная реализация mandoc.

P.S. История развития документации UNIX — manpages.bsd.lv/history.html
> В третьей части «Руководства по автоматизации тестирования», я расскажу вам о том

Лучше не надо.

Где вы находите эти статьи для перевода? От них веет годом этак 2005-м.
Если вы хотите сделать рекламу для своих курсов, то может лучше найти что-то поактуальнее? И вам польза будет и читателям.
> Как защититься

использовать проверку с помощью моделей (model checking) для проверки алгоритмов (TLA+, Spin/Promela) и для проверки кода. Динамический анализ, например Thread Sanitizer.
«Сейчас для меня умный дом это то, что работает само без моего участия, и не требует управления.»

это очень ценная мысль

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity