Girar/Development

Abstract

Эта страница описывает актуальные задачи развития инфраструктуры Girar. Задачи заносятся в bugzilla (продукт Infrastructure, компонент git.altlinux.org) как FR.

Цель

Развитие инфраструктуры Girar преследует следующие цели:

• Повышение качества пакетов, собираемых для Sisyphus и/или производных продуктов;
• Снижение нагрузки на майнтейнера пакета в Sisyphus и/или производных продуктах при выполнении рутинных операций;
• Создание майнтейнеру дополнительных возможностей автоматического/автоматизированного тестирования пакетов;
• Создание условий для разработки сторонних систем взаимодействия с инфраструктурой Girar

Задачи

"Результат сборки задания как репозиторий"

• Задача: обеспечение удобного способа тестирования test-only заданий
• Требуемые доработки:
  • Предоставление собранных файлов как репозитория, пригодного для подключения как rpm-dir
  • Короткий URL репозитория (например, http://git.altlinux.org/repo/21788/ i586 hasher)

altbug:23934

"Персональный репозиторий-клон"

Направление развития относится к т.н. "Карманам".

• Основная решаемая задача: дать инструмент проведения масштабного эксперимента над базовым репозиторием (Sisyphus или производным продуктом).
• Как будет работать: по команде пользователя создаётся copy-on-write клон указанного базового репозитория с выдачей инициатору прав суперпользователя в пределах нового репозитория. В дальнейшем над получившимся репозиторием производится необходимый эксперимент группой майнтейнеров и тестирующих пользователей.
• Ограничения: Для предотвращения ненужных форков время жизни "персональных репозиториев-клонов" должно быть ограничено.

altbug:23935

"Персональное дополнение к репозиторию"

Направление развития относится к т.н. "Карманам".

• Основная решаемая задача: Долгоживущая сборка пакета (или группы пакетов) для базового репозитория (Sisyphus или производного продукта) без публикации результата в базовом репозитории. Получившийся результат должен постоянно оставаться совместимым с базовым репозиторием (например, должна производиться автоматическая пересборка дополнения при изменении его сборочной среды). Пример usecase-а для таких "дополнений": backport.
• Способ функционирования: Для каждого базового репозитория должен поддерживаться список существующих "дополнений". При изменении репозитория должен формироваться список "дополнений", требующих пересборки и должна инициироваться их фоновая пересборка.
• Ограничения: Должны быть разумные причины существования подобных "дополнений", поскольку они требуют вычислительных ресурсов.

"RESTful API"

• Для взаимодействия сторонних информационных систем с Girar требуется наличие машинно-пригодного интерфейса взаимодействия. Предлагается разработать HTTP-шный интерфейс взаимодействия. В качестве формата данных предполагается использовать JSON.
• Замечание. Write-действия требуют аутентификации, а ssh-ключ не подходит для использования по HTTP. Предлагается реализовать возможность изменения (посредством ssh git.alt) пароля и включение/выключение write-доступа.

"Web-interface"

• В условиях существования "Персональных репозиториев" и "Дополнений к репозиториям" хочется иметь web-интерфейс для визуализации/поиска/etc.
• Предусловием реализации является наличие "RESTful API". Также потребуется завести такие сущности как "теги" и "описания" для караманов любого вида и заданий.

"Публичный build service"

• Основная решаемая задача: Создание условий стороннему прикладному разработчику (не являющемуся разработчиком Sisyphus) собрать своё приложение для Sisyphus и/или производного продукта. Необходимо обеспечить автоматическую сборку залитого пакета под определённый набор репозиториев (автоматический бекпорт). Предполагается, что данная возможность будет доступна всем самозарегистрировавшимся через web-интерфейс "Публичного build service".
• Способ функционирования: Функционирует как "Дополнение к репозиторию" в отдельной (без разделения unix-пользователей) сборочнице.

"Инфраструктура тестирования"

• Изначальная постановка задачи: ab@
• Задача: Существует некоторое количество сложных пакетов, тестирование которых требует наличие нескольких многомашинных конфигураций (пример - samba). Далеко не каждый майнтейнер обладает подобной собственной инфраструктурой для проведения полноценного тестирования. Требуется разработать систему создания/хранения/исполнения подобных многомашинных (виртуальных) окружений.
• Способ функционирования: требует продумывания. Пока ясно, что требуется возможности по:
  • созданию,
  • хранению,
  • исполнению,
  • связыванию

виртуальных машин. Требуется учесть, что во многих конфигурациях потребуется наличие виртуальных машин с ОС, отличными от ALT Linux (win, другие дистрибутивы,...)