Re: [devel] srpms -> gear

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

PreScriptum: это письмо является лоскутным и отчасти
просится в smoke-room@.

On Tue, Jul 03, 2007 at 01:28:36PM +0400, Dmitry V. Levin wrote:
> > У меня пока привыкание остановилось на подходе к apache и
> > xmms (2 solo: помню, но ещё всё так же не смотрел -- видимо,
> > уже на кофнференции).  Поскольку патчи из разных мест,
> > которые поддерживаю не я, пока возможней поддерживать со
> > старым добрым src.rpm, чем в гите.  Проблема в том, что эти
> > два апстрима, мягко говоря, консервативные и продавить их
> > туда уже не особо реально.
> gear-репозиторий, который получается на выходе gear-srpmimport,
> ни чуть не сложнее srpm-пакета, верно?

Дим, просто не знаю.  Я сейчас решил подождать, пока более
светлые умы придут к консенсусу (а мож и git поправят про
те же частичные вытяжки).

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

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

> > > Видимого смысла в srpm-паетах после миграции на
> > > gear-репозитории не будет.
> > Было бы всё-таки хорошо иметь какой-то простой вариант
> > понять, чем отличается пакет от upstream tarball.  Причём не
> > глазами разработчика (им проще), а скорее глазами опытного
> > админа.
> gitweb?

Неочевидно, http://sisyphus.ru/srpm/xmms/patches намного
юзабельней. (из cvs.pld-linux.org тоже патчи выковыривать очень
неудобно, но они используют CVS где-то как rider@ упоминал:
хранилище, не более)

> > Повторюсь, если мы собираемся заниматься серверами и иметь
> > толковые инструменты их администрирования -- следует
> > привлекать опытных админов, поскольку "толк" в инструментах --
> > это как раз замороженный в бэкендах опыт администрирования,
> > как вот и толк в пакетах -- замороженный в спеках опыт
> > сборки.
> Среди нас есть опытные админы, не являющиеся по
> совместительству разработчиками?

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

Вовсе не каждый человек, который может быть очень полезен ALT
Linux как проекту, должен быть или стать разработчиком в плане
понимания кода на C и нюансов autotools или вот git.

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

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

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

taf@, dlebkov@ или force@ -- весьма уважаемые мной скорее админы,
чем разработчики.  Просто сильно подозреваю, что как админы они
тоже эффективней, чем как разработчики.

> > Сейчас как минимум то, что твой репозиторий для получения
> > списка пакетов обрабатывается в среднем ближе к минуте --
> > тоже не помогает знакомиться с наработками.
> Зачем человеку может срочно понадобится список всех моих
> пакетов?  Я сам на него стараюсь не смотреть. :)

Для того, чтобы пойти посмотреть один из них.  Это может быть
решено иначе -- например, прикручиванием к sisyphus.ru прямых
ссылок, поскольку они предсказуемые -- но у меня сейчас не на
кого свалить доработку sisyphus.ru хотя бы в рамках багов на
пакете prometeus.

> P.S. Почему gitweb на этой операции так сильно тормозит?

Предположительно потому, что генерится вагон I/O.  Очень помогает
не сваливать всё на системе на один набор связанных по I/O дисков
и разводить параллельно выполняющиеся операции (например, на
одной паре дисков -- веб, на другой -- операции над
репозиториями).

Свежий пример приводится в конце письма.

> > Бишь даже с имеющимися концептуально крутыми инструментами
> > есть досадные практические проблемы вроде отсутствия
> > кэширования дорогих по времени получения результатов в
> > gitweb.
> todo++; чем лучше кэшировать?

Мож mithraen@ или at@ расскажут, чем из имеющихся кэширующих
прослоек на перле лучше пользоваться.  Я точно знаю, что эта
проблема свойственна многим веб-проектам и при растягивании
их на масштабируемость её приходится решать.

Очень приблизительно -- "слепить html-страничку и если даты
модификации чего-то, например каталогов, не моложе времени 
генерации -- отдавать её до устаревания".

Ещё может иметь смысл нарисовать на gitweb robots.txt и/или
зарегистрировать в Google Webmaster Tools и сказать лазить
пореже, если в access_log большая доля роботов.

Если там до сих пор нет nginx фронтэндом (reverse proxy)
-- очень рекомендую, можешь уточнить у lakostis@ эффект.
У меня схожий наблюдается.

-------------------------------------------------------------

Ммм... если это был i965 с добавочным контроллером JMicron, тогда
понятно (в ALT 4.0 Server вроде победили, но пока сам не
проверял).  Эти ж-микроны -- действительно гадость редкая.

А вот на GA-M55PLUS-S3G вчера помимо обычной работы проводили
стресс-тест, машинка достойно выдержала.  Он был такой:

- имеется эта мамка, X2 4400+ на ней, 4G DDR2-667, 2+2 SATA-диска
  и 1 SCSI
- установлен ALT 4.0 Server (ядро 2.6.18 с поддержкой OpenVZ)
- в одном VPS запущен офисный терминальный сервер, на нём пять
  клиентов болтаются
- в другом VPS -- 32-битная сборочница
- в третьем -- 64-битная сборочница
- и ещё с полдюжины контейнеров, которые особо не отсвечивают

Раньше сборка проводилась на SCSI, но пакеты для формирования
build chroot (довольно тяжёлая операция в плане I/O) брались с
тех же двух SATA-дисков, на которых в RAID1 живёт LTSP5.  А тут
"I" для сборочниц вынесли на отдельные два шпинделя.  В общем,
если на одном диске (на рабочей станции с гигом памяти и быстрым
процессором) такие три сборки параллельно запустить -- можно
вешаться, всё будет ползать.  Здесь же полностью развели
ввод-вывод и при офигенной загрузке на терминалах можно было
просто работать.  Ну опенофис запускается не две секунды, а 15,
если не из кэша (будучи один раз запущен -- опять за две
взлетает).  Ну подкрутили приоритеты, выдали терминал-серверу на
порядок большую долю процессорного времени и вообще незаметно,
что там за стенкой всё колбасится. :) 

-------------------------------------------------------------

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