Вход:  Пароль:  
FreeSource: AltLinux/Concepts/KudaIdetSisyph ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Вопрос о будущем ALT Linux вообще и Сизифа в частности всегда был (и есть) на повестке дня. Итак, куда же идёт Сизиф?


Относительно недавно (точнее, 31.08.2006) в лист рассылки devel@ пришёл такой анонс:


From: Aleksey Novodvorsky <aen@>
Subject: [devel] Новый Сизиф
To: devel@
Date: Thu Aug 31 18:30:16 2006 +0800
Reply-To: ALT Devel discussion list <devel@>

Коллеги,
предлагю для обсуждения конспект бесед о виртуализации в Сизифе, которе
вели nidd, ldv, inger, smi, aen, а на более ранних этапах — kirill и george.
Конспект состоит из текста и картинки.
Можно взять все вместе здесь http://lrn.ru/~aen/new_sisyphus/ в зипованом html или pdf, или только картинку 
http://lrn.ru/~aen/new_sisyphus/va_vmm-1.png,  а текст прочитать ниже.

Новый сизиф.
Конспект обсуждений с участием nidd, ldv, inger, smi, kirill, george.
1. Сизиф, сохраняя преемственность, становится средством для создания,
отладки и управления Virtual appliance (далее VA). По сути, под законченным "решением" мы теперь понимаем VA.
Разрабатывается Sisypus versioninig policy для обеспечения
сосуществования нескольких версий пакетов.
1.1. Средствами создания VA, являются hasher и (более высокого уровня)
— доработанный и документированный spt.
2. Создается    новый репозиторий (?) — Sisyphus bazaar (название
раскритиковано, оставлено здесь временно), 
состоящий из VA. VA бывают 1) ALT и 2) non-ALT. Первые удовлетворяют
ALT VA policy (см. ниже)
Любой VA работает под управлением Supervisor — специализированной OS.
Supervisor может входить или не входить в Sisyphus.
3. (См. картинку)
3.1. ALT VA система поддерживает как VA соответвующие ALT VA policy,
так и не соответствующие им. Первые называются ALT VA.
3.2. ALT VA система может работать на системе виртуализации
поддерживающей требования ALT Supervisor policy. ALT предоставит свою
систему виртуализации, однако она может быть заменена на другие.
3.3. Разрабатывается ALT VA policy ( ниже краткий план):
3.3.1. Взаимодействие VA с окружающим миром производится посредством
шины передачи данных предоставляемой Supervisor.
3.3.2. Управление и настройка VA производится посредством
configuration шины (шины управления) по протоколу управления
alterator. ALT VA обязан поддерживать этот протокол управления. Должна
обеспечиваться
возможность настройка системы исключительно с помощью протокола
управления alterator (возможно довести систему до требуемого состояния
используя исключительно протокол alterator).
3.4. Разрабатывается Supervisor policy (ниже краткий план):
3.4.1. Supervisor должен предоставлять возможность создания двух шин объединяющих VA: шины передачи данных (Data bus) и шины управления и конфигурации (Configuration bus).
3.4.2. Supervisor должен распределять физические ресурсы между VA.
3.4.3. Supervisor должен предоставлять API для управления собой.
3.4.4. Подерживаемые ALT VA supervisors: OpenVZ, Xen, VmWare, Virtuozzo.
3.5. Разрабатывается ALT System policy (ниже краткий план):
3.5.1. ALT System включает маршрутизатор, Supervisor, модуль
управления Supervisor, управляющую систему и набор VA.
3.5.2. Модуль управления Supervisor позволяет управлять Supervisor
используя предоставленный им API. Обращение к модулю рекомендуется
осуществлять через протокол alterator.
4. Для координации работ в рамках проекта Sisyphus вводится должность
Секретаря проекта. Секретарь  отслеживает состояние проекта во всех
его аспектах и раз в месяц публикует отчет о нем. Секретарь != лидер
проекта.

Когда это начнётся? Уже началось. Подробнее:


From: Aleksey Novodvorsky <aen@>
Subject: Re: [devel] Новый Сизиф
To: ALT Devel discussion list <devel@>
Date: Mon Sep  4 19:49:59 2006 +0800
Reply-To: ALT Devel discussion list <devel@>

Eugene Prokopiev пишет:

>Как этот проект связан с релизом Сизифа? Его планируется начать после 
>релиза во время разморозки?

Масштабно — да.

Для тех, кто не (совсем) в теме, про VA и с чем его едят: здесь есть краткое введение.


Вот как aen@ высказывается по этому поводу:


Операционные системы в широком смысле («дистрибутивы»), как мы их видим сейчас, уходят в прошлое. В одной системе можно будет запускать несколько VA разного назначения, с разными (возможно) ядрами. Сизиф всегда был средством разработки, основой для создания решений, таким он и останется. Но вот сами решения будут выглядеть иначе.


Отсюда я (для себя, разумеется) делаю вывод, что Сизиф (и ALT Linux вообще) будет переставать позиционироваться как продукт(ы) для широкого круга потребителей/пользователей (уже?). Заметный крен в сторону админов/хакеров/строящих своё думаю, только усилится. Разумеется, кого-то эта информация огорчит/разочарует, но это лучше, чем обманывать ожидания.


Ссылок на эту страницу нет


 
Файлов нет. [Показать файлы/форму]
Комментарии [Скрыть комментарии/форму]

(а закину-ка сюда подборку, сделанную на одном форуме про альт — думаю, главное понятно и не зная украинского)


Наприклад, в нас зараз такий toolchain є:


rpm: встановлення/видалення/поновлення пакунків із скриптами на ці події та обробкою поновлення конфігів
apt: рівень вище, ніж rpm — дозволяє автоматичне врахування залежностей (в тому числі при їх зміні)
# це було корисно усім, а далі переважно розробницьке
hasher: генерування чрутів заданого складу за допомогою apt та fakeroot з наданого репозиторію пакунків
gear: збирання пакунків за допомогою hasher безпосередньо з розробницького git-репозиторію
# а це — розробнику дистрибутивів та адміну
spt: генерація ISO (livecd, installer) чи тарболів (для контейнерів openvz чи vserver) за допомогою hasher
control: простий фреймворк для керування об'єктами системи


Все це дозволяє автоматично вирішувати завдання того рівня, вирішення яких таким чином для слакварі неможливе; ми про те із Хотабичем та Сколотом спілкувались — не вистачає %pre/%postun IIRC скриптів, залежностей пакунків того рівня коректності, щоб вистачало мінімального списку «кінцевих» потреб для підтягування усього, що їм треба: наприклад, template cache для openvz нещодавно робив із $SPTDIR/profile/packages/main вигляду basesystem apt etcnet glibc sysklogd (s/ /\n/g).


Втім, в людей дійсно може просто не бути завдань цікавіше за localhost... а тоді дистро неважливий, були б люди хороші.

-- MichaelShigorin (2006-10-05 11:03:23)

pere.org.ua'вод поправленный:


Например, у нас сейчас такой toolchain есть:


rpm: установка/удаление/обновление пакетов со скриптами на эти события и обработкой обновления конфигов
apt: уровень выше, чем rpm — позволяет автоматический учет зависимостей (в том числе при их смене)
# это было полезно всем, а дальше преимущественно разработческое
hasher: генерирование чрутов заданного состава с помощью apt и fakeroot из предоставленного репозитория пакетов
gear: сборка пакетов с помощью hasher непосредственно из разработческого розробницького git-репозитория
# а это — разработчику дистрибутивов и админу
spt: генерация ISO (livecd, installer) или тарболов (для контейнеров openvz или vserver) с помощью hasher
control: простой фреймворк для управления объектами системы


Все это позволяет автоматически решать задачи того уровня, который для слаквари невозможен; мы о том с Хоттабычем и Сколотом общались — не хватает %pre/%postun IIRC скриптов, зависимостей пакетов того уровня корректности, чтобы хватало минимального списка «конечных» потребностей для подтягивания всего, что им надо: например, template cache для openvz недавно делал с $SPTDIR/profile/packages/main вида basesystem apt etcnet glibc sysklogd (s/ /\n/g).

-- MichaelShigorin (2006-10-05 11:06:22)