Поэтому, я бы брал упомянутый тесткитчен и городил бы полностью параллельный BDD огород

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

привет puppet :)

т.е. вот Ansible - это инструмент автоматизации, т.е. повторения императивных действий

а папет как раз позволяет описать систему и сам её как-то к этому состоянию приводит

Инструмент повторения императивных действий это Fabric

А также и Func

Инструмент повторения императивных действий это Fabric

ок, согласен, Ansible тоже оперирует микростейтами в некоторых модулях

но не во всех

Ну - потому что некоторые вещи не можно выразить идемпотентно

и всё равно это лишь способ не совершать действие, если оно уже сделано

Нет

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

все эти стетйты можно развернуть в императивные if-ы

Если действие уже сделано - и второй прогон делать не надо, это и есть идемпотентность

все эти стетйты можно развернуть в императивные if-ы

Ну, что угодно можно

Если действие уже сделано - и второй прогон делать не надо, это и есть идемпотентность

ну ок

Это top-down approach

Мы хотим наоборот

Ну, что угодно можно

О! Это вот правильная мысль

и у нас есть отдельный BDD зоопарк

Если действие уже сделано - и второй прогон делать не надо, это и есть идемпотентность

А если действие сделано, потом изменен темплейт и снова все действия - это как назвать?

Мы же хотим повышать уровень абстракции

Ну, что угодно можно

и у нас есть отдельный BDD зоопарк

Но так, чтобы без протечек

и у нас есть отдельный BDD зоопарк

хм...

А если действие сделано, потом изменен темплейт и снова все действия - это как назвать?

Ну - нормально, перегенерация всего

А если действие сделано, потом изменен темплейт и снова все действия - это как назвать?

это другое действие, которое еще не сделано

Уебищная система, из-за одного изменения весь темплей гнать

Уебищная система, из-за одного изменения весь темплей гнать

ну можно делать diff и накатывать patch

а смысл?

он ровно сделает тоже, запишет в FS новый файл

Но время же...

на проверку старых значений и т.п., т.е. diff тот же.. однохуйственно

Но время же...

не факт, что diff быстрее

а вот другое, как с помощью BDD проверить state=restart ?

на проверку старых значений и т.п., т.е. diff тот же.. однохуйственно

именно

А ни как.. это же тот же stop; start

Или я ошибаюсь?

а вот другое, как с помощью BDD проверить state=restart ?

Pid другой

а вот другое, как с помощью BDD проверить state=restart ?

Ну - по делам их узнаете их

а вот другое, как с помощью BDD проверить state=restart ?

т.е. вот у меня есть фигулка, которая на changed шлет notify на restart. как мне в тестах проверить, что restart был?

Что меняет рестарт?

Поведение сервиса?

Проверяй смену поведения сервиса

Pid другой

как я декларативно опишу старый pid?

У тебя сервис должен всякие крючочки предоставлять для интеграции с BDD

как я декларативно опишу старый pid?

Нене, это херня

Версия бампнется на вебморде, например

Проверяй смену поведения сервиса

ну т.е. аудит поведения делать, а не состояния

ну т.е. аудит поведения делать, а не состояния

Чо

Поведение это и есть состояние

не совсем

ERROR: S client not available

“Состояние” = “сервис имеет версию 2.1”

А если не было рестарта - то и не имеет

“Состояние” = “сервис имеет версию 2.1”

но я не могу описать это в отрыве от сервиса. мне надо знать как эту версию посмотреть и в каждом сервисе оно делается по-разному :(

это слегка расстраивает :)

Ну - сорян, плохо быть тобой

В самописных сервисах ты это можешь унифицировать

В написанных не тобой, например, в монге….

Кстати, как к тебе в проект вообще попала монга?

А, погоди

В монге это делается легко

не, ну я могу всё в докер и проверять образ, из которого родился бегающий щас контейнер

Там однострочник все покажет

не, ну я могу всё в докер и проверять образ, из которого родился бегающий щас контейнер

О

Вот взгляд правильный и расовый

но всё равно, не нравится мне совсем параллельный зоопарк иметь...

Не вижу проблем

Энсибл императивен, с этим ничего не сделать

Не вижу проблем

но если задуматься, в тестах в программировании так же ведь

Все попытки сделать декларативную CM tool поверх императивного Linux пока проваливались

но если задуматься, в тестах в программировании так же ведь

Так это понятно почему

Энсибл императивен, с этим ничего не сделать

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

о! вот оно!

вот же оно! вот что мне в этом не нравится.

Ну - наверное

Я пока думал о другом