[sisyphus] Надёжность Sisyphus

["Денис Смирнов" <mithraen@freesource.info>]

On Thu, Nov 13, 2003 at 04:58:57PM +0200, Michael Shigorin wrote:

 >>>> невозможно, то установки по-умолчанию должны быть
 >>>> максимально близки к тому, что было до обновления, а
 >>>> информацию об изменениях кроме как на stderr админ должен
 >>>> получить на root@.
 >>> Это подразумевает рабочий почтовик.  Т.е. уже серьезно.
 >> Есть другие предложения? Я ничего кроме stderr с дублированием
 >> на почтовик не вижу.
 > Я только за (при условии почты _только_ с проблемами... но это
 > личное, а по-хорошему -- должно регулерироваться).
 > Сделаете?

Хм. Кажется я нечётно сформулировал свою мысль. Попробую сначала.

Проблема: периодически попытки обновиться из сизифа приводят к
неработоспособности системы.

Задача: техническими и/или административными методами уменьшить
вероятность получения системным администратором по голове от руководства
и клиентов при попытке пбновиться.

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

Причины:
 - ошибки в upstream
   С этим борется каждый мантейнер как может, гарантированых решений быть
   не может. Улучшить ситуацию можно:
   1. автоматическими тестированиями;
      
      как реализовать это на практике в общем виде я себе представляю
      слабо, однако для таких продуктов как PHP вполне можно реализовать
      набор тестов (хотя бы анализ того, что возвращает phpinfo() ).
   
   2. тестированием в условиях приближеных к боевым в течении нескольких
      дней группой из тех, для кого развитие этих пакетов является важным,
      и кто, возможно, своей головой будет отвечать за работоспособность и
      функциональность сервисов на базе данного пакета, используемых в его
      организации.

      уточнение: тестирование не _всех_ пакетов, а только тех, которые
      персонально для него важны.

      как реализовать: разделить сизиф на два уровня, новые пакеты всегда
      добавляются в один из уровней, если за неделю никаких изменений в
      нём не было (или на него не висит в BTS block-bug'ов), то
      автоматически переносить его в основной репозитарий. Вся эта работа
      должна выполняться автоматически, без участия человека (что снизит
      нагрузку на incominger'ов заодно).

      при этом иметь список людей (привязаный к каждому пакету)
      заинтересованых в том, чтобы отслеживать развитие данного
      конкретного пакета, речь идёт о людях _не обязательно_ являющихся
      членами Team.

      соответственно это даст возможностям людям принимать решения,
      насколько они готовы быть тестерами (то есть тестировать совсем
      сырые версии пакетов, или уже хорошо протестированые).

 - ошибки в пакетах
   1. тестирование вроде приведённого выше;
   2. продуманое полиси, в котором будут перечислены вещи, на которые
      важно обращать внимание.

      собственно мои мысли на тему "при обновлении не должна меняться
      конфигурация", "если при обновлении меняется конфигурация, это повод
      срочно проинформировать админа, да ещё и так, чтобы он эту
      информацию потерять лишь с большим трудом мог", "при обновлении
      нельзя вносить изменения, которые могут блокировать удалённый доступ
      администратора к серверу" (это я всё pam вспоминаю), "средства
      коммуникации, журналирования, авторизации должны тестироваться особенно
      тщательно, и нарушение их работы недопустимо даже в Sisyphus" это
      исключительно мысли, которые, IMHO, имеет смысл в развёрнутом виде
      иметь в таком полиси (рекомендательно-объяснительного характера, ибо
      проверять каждый пакет на соответствие _перед_ добавлением в сизиф
      нереально ни для кого, кроме самого мантейнера).

      поэтому реализовать техническими методами то же информирование я не
      могу -- для этого мне надо добавить это во все пакеты, которые этого
      требуют.
   
 >> К тому же ситуация, при которой обновление может блокировать
 >> работу почтовика, является одной из той, опасность которых
 >> мейнтенерам хорошо бы учитывать и стараться преодолеть. Хуже
 >> падения почтовика может быть только падение sshd или проблемы с
 >> pam (не считая потерь данных, конечно).
 > Вот.  А тут добавляется еще одно требование его живости.

Сейчас эта информация просто теряется. Я же предлагаю её в бОльшей части
(заметно большей чем 99% случаев) давать возможность изучить
администратором. Ситуации, когда после обновления почтовик умирает так,
что даже его очередь гибнет, насколько мне известно, пока не встречались
(и слава богу).
 
-- 
С уважением, Денис

http://freesource.info