Ставлю на виртуалках и сперва сделал опечатку в хостнейме на первом хосте, теперь у меня вот этот пидфайл висит на ceph01 и ceph-deploy purge ceph01 не помогает:

root@ceph01:/var/run/ceph# ls
ceph-mon.cdph01.asok

root@ceph01:/var/run/ceph# ls
ceph-mon.cdph01.asok

То есть я перепроверил все /etc/hosts, /etc/hostname и записи в админской машине, все равно он запускается с неправильным файлом ceph-mon.cdph01.asok вместо ceph-mon.ceph01.asok

Короче ceph-deploy purge вот это дерьмо не чистит: /var/lib/ceph

Еееее, завелось на 3 виртуалочках! Правда в octopus дешборд требовал distutils.dist модуля - хоть он в питоне3 и был, дешборд вроде бы работает без него.

"Проблема" rook на мой взгляд не в самом rook, а в том, что за него берутся люди, никогда не читавшие документацию Ceph. Большей части бед с rook можно было бы избежать, если бы yaml-девелоперы вместо того, чтобы сразу выполнять Quick Start из документации rook, сначала развернули Ceph ручками, поломали различным способом, посмотрели на поведение, и выучили бы его документацию как отче наш. Хотя бы этого уже было бы достаточно, чтобы спасти данные в большинстве умерших rook-кластеров, с которыми сюда приходили.

За исключением конкретно вот этого бага, но тут пострадавших трое на весь мир, и проблема вроде как на стороне k8s, а не rook (но есс-но админам этих трёх кластеров от этого не легче).

ну это общая проблема девелоперов, не только руук, но и тех же цефадм. Они девелопят фичи на 3-5 виртуалках в самой простейшей конфигурации.
Они тестят что-то, но конфиг слишком простой.

а про оперативные действия, понятия вообще не имеют

нужно бы какой-то тест протокол от админов и операторов живых кластеров

есть куча тестов в тутолоджи, вот на них и надеятся )))

большинство из поломай/почини это цеф, с оркестрацией мало общего, но да, добавление, удаление осд, мониторов, гейтвеев надо лучше тестить

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

ну это да, но руук много и не даёт ямл девелоперам. что они там контролируют, афинити и какие диски он жрёт

вот например, админ устранен от мониторов практически вообще

в том то и суть яамл программирования, что думать не надо )))

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

Так им больше и не надо. Хватит понимания, что у rook под капотом, чтобы совсем глупые ошибки не делать, да знать когда остановиться в собственных попытках починки упавшего кластера. Для этого хватило бы документации, да небольшого практического опыта с ручной установкой.

Тут следует заметить, что это багрепорт от одного из разработчиков https://github.com/rook/rook/pulls?q=is%3Apr+author%3ABlaineEXE+is%3Aclosed а пользователи на конкретно эту проблему видимо не натыкались. То есть сами выловили, сами починят. А то что админ устранён от ручного управления - ну так это by design.

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