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

[Michael Shigorin <mike@osdn.org.ua>]

[-- Attachment #1: Type: text/plain, Size: 8596 bytes --]

On Fri, Nov 14, 2003 at 02:35:52AM +0300, Денис Смирнов wrote:
>  >> Обоснование: обновление из сизифа часто является
>  >> вынужденым, даже если человек и не хочет принимать
>  >> активного участия в разработке, по таким причинам, как
>  >> отсутствие багфиксов к Мастеру, за исключением security.
>  > Ммм... в таком случае может быть более осмысленно
>  > поддерживать локальный репозиторий бэкпортов.  У меня в
>  > некоей форме такое водится, по крайней мере leafnode и
>  > apache на alm2.2-системы попадают именно так.
> Это решение со стороны администратора, на текущий момент
> единственное и оптимальное.

Ну да.

> Я сейчас смотрю на проблему и методы её решения со стороны
> разработки дистрибутива.

А эта сторона станет возможной разве что при:

1) возникновении сильного и стабильного реплзитоиря таких
   бэкпортов;
2) принятия его "под крыло" alt.

>  > Если критичность * общесть проблемы превышает некий
>  > субъективный порог -- может быть оправданно рекомендовать
>  > (org@?) включение таких пакетов в updates после проверки.
> Думаю что лучше всего если будет некий унифицированый подход.
> Чем меньше исключений из правил, тем меньше шансов сделать
> что-нибудь не так.

Ох.  Да тут еще дожить до этих правил надо.

Причем не в виде трепа в рассылке с умным видом, а в виде
созданного, зафиксированного, опубликованного и уважаемого
документа.

(у меня с этим проблемы)

>  >> Причины: - ошибки в upstream
>  > Есть updates, которые errata.  Для критичных ошибок они
>  > могут выпускаться.
> Могут не значит выпускаются. Увы.

Ессно.

> Сейчас у админов нет выхода, кроме как либо заниматься
> пересборкой пакетов из сизифа

Обычно срабатывает с этакой себе экспоненциально убывающей по
мере удаления сизифа от предыдущего релиза вероятностью.

Есть "объезды" в виде точечных включений в ~/.rpmmacros (вроде
%__subst), но уменьшение дублирования усилий может быть
осмысленным.  Может стать слишком тяжким бременем, правда.
(собирать бэкпорт nvidia/alsa для ядер из updates/Master/2.2 я
довольно давно обломался -- кажется, после очередной перемены по
kernel-headers-*, когда уверенность в пригодности результата
сильно снизилась, а проверить было уже почти негде)

> либо обновляться до сизифа во многих случаях.

Тестовая система.  Однозначно.

>  >>    1. автоматическими тестированиями;
[...]
>  >>       того, что возвращает phpinfo() ).
>  > Анализ по каким критериям?
> Например соответствия тому, что утверждает PHP на предмет подключеных
> модулей тому, что по этому поводу говорит rpm -qa | grep ^php-
> Таких автоматических тестов придумать можно много. Вопрос

А, вот как.  Это было бы неплохо (разве в данном конкретном
случае непонятен момент с подключением/неподключением модулей по
умолчанию: есть мысль, что некоторые из них могут быть упакованы
с тем, чтобы требовать _явного_ поворота рубильника).

>  > >    2. тестированием в условиях приближеных к боевым в
>  > >    течении нескольких дней группой из тех, для кого
>  > >    развитие этих пакетов является важным, и кто, возможно,
>  > >    своей головой будет отвечать за работоспособность и
>  > >    функциональность сервисов на базе данного пакета,
>  > >    используемых в его организации.
>  > Так без него критичность не определяется в любом случае.

(слишком мало вводных)

> Не понял реплику.

Без тестирования.  И без "того, кто отвечает головой".

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

Нет.

> каждом закрытии каждой (не только ими выставленой) баги?

Можно подписаться на пакет IIRC.

>  >>  - ошибки в пакетах
>  >>    1. тестирование вроде приведённого выше;
>  >>    2. продуманое полиси, в котором будут перечислены вещи, на
>  >>       которые важно обращать внимание.
>  > Ммм... боюсь, обобщить тестирование -- проблема еще та, судя
>  > по количеству живой силы на этой задаче у поставщиков
>  > коммерческого ПО.
> У поставщиков коммерческого ПО большие силы уходят на то, чтобы
> тестировщик был заинтересован в тестировании. В случае
> free-software community об этом заботиться смысла нет,

Ой ли.

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

Это заинтересованность в донесении результатов тестирования.
С точки зрения BTS -- одно и то же. :)

> Тем более что даже зубры ошибаются.

Ага... и при этом разлет щепок больше :-/

>  >> собственно мои мысли на тему "при обновлении не должна
>  >> меняться конфигурация",
>  > Зависит.  Иногда известно, что с имеющейся конфигурацией
>  > новый код попросту не взлетит.
> Вот тогда нужно уведомлять об этом админа, причём эти
> уведомления должны содержать в себе инструкции на тему как и в
> какую сторону можно ситуацию разрулить.

Ну, это "в идеале". (вспоминая раздумия над подобными сообщениями
при их составлении)

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

Они могут быть и _не_известны заранее.  Например, когда
майнтейнер предпринял достаточно разумные и адекватные меры по
переезду, но локальная специфика аукнулась.

Такие варианты остается принять как данность, предусмотрению
_все_ они подлежать не могут по определению.

>  >   Примерно так уже сделано в Debian; у нас хотелось бы вырулить
>  >   на то, информацию о чем можно получить той же почтой и
>  >   отфильтровать по порогу, причем в идеале -- иметь возможность
>  >   подвесить туда же робота (доступного в дистрибутиве), который
>  >   может, глядя на подпись и некоторые иные критерии (тот же порог
>  >   важности) -- дернуть rsync и/или apt и/или /bin/mail.
> Опа, мы кажется немного о разных вещах говорим :(

Да нет, об одной -- просто разрешаться она может в runtime или
раньше.  IMCO лучше -- как раз раньше, хотя это не меняет
необходимости отработки и runtime "по-хорошему".

> Я говорил изначально о нотификации изменений _после установки_,
> потом это уже спуталось с другой моей идеей -- нотификацией
> заинтересованых лиц в выпуске нового пакета.

Админ sisyphus-системы -- тоже лицо заинтересованное.  Или не
админ, или не системы.

>  >>       "если при обновлении меняется конфигурация, это повод
>  >>       срочно проинформировать админа, да ещё и так, чтобы он
>  >>       эту информацию потерять лишь с большим трудом мог"
>  > Ммм... *.rpmsave?
> И это тоже. Однако информацию о том, что изменилось значение
> по-умолчанию какой-то переменной оно содержать не будет, и если

Это changelog, большего требовать нельзя.

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

Технически это разве что diff.  ("установочные скрипты на прологе
или лиспе писать -- не предлагать!" :)

>  > Проблема в том, что люди, которые отвечают за базовые средства
>  > удаленного доступа и контроля/смены привилегий -- a priori
>  > полагаются более чем сведущими в вопросе.
>  > Соответственно что делать с этим вопрсом -- непонятно.
> Только подразумевать то, что даже Величайшие Гуру являются
> всего лишь живыми людьми и склонны хотя бы иногда ошибаться.

Одно из моих правил -- "человек _всегда_ имеет право на ошибку".
(применительно к другим)

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

Возможно.  Но для этого должно как минимум наступить осознание
своей возможности ошибаться, блин.

>  >>>> К тому же ситуация, при которой обновление может блокировать
>  >>>> работу почтовика, является одной из той, опасность которых
>  >>> Вот.  А тут добавляется еще одно требование его живости.
>  >> Сейчас эта информация просто теряется.
>  > Лог?
> В каком логе была информация о изменении структуры конфига в
> PHP?

В changelog 1:4.3.4-alt0.cvs20031017.  Сжато, но в целом --
нормально. (стоило WARNING или еще какого-нибудь принятого
ключслова?)

> Или о изменении поведения su?

Чуть ли не мимоходом в рассылке.  В режиме "я не ошибаюсь"?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]