LXD 2.0: Отладка и вклад в LXD [12/12].

Стефан Грабер (Stéphane Graber) опубликовал последний пост в рамках цикла из 12 статей про LXD. Как найти проблему, если она возникла? Как правильно оформить отчёт об ошибке и куда его отослать?

Введение

Наконец-то, финал! Серия из 12 статей, начавшаяся год назад, заканчивается. Если вы следили за серией с самого начала, то получили базовые знания про LXD, чтобы знать про его возможности и как использовать в своей практике.

Но что если что-то пойдёт не так? Как самому найти ошибку? И если сами не сможете исправить, какую информацию нужно собрать для апстрима, чтобы они смогли понять в чём суть проблемы и исправить её? А что, если вы хотите помочь и исправить проблему сами или добавить классную фичу? Как собрать, оттестировать и передать свою наработку в кодовую базу LXD?

Отладка LXD и отчёты об ошибках

Журналы LXD

/var/log/lxd/lxd.log
Главный журнал LXD. Чтобы быстро не переполнить ваш диск, только сообщения INFO, WARNING и ERROR пишутся в данный журнал по умолчанию. Изменить поведение и повысить уровень отладки можно, передав -debug демону LXD.

/var/log/lxd/CONTAINER/lxc.conf
Всякий раз, когда стартует контейнер, данный файл обновляется данными конфигурации, пришедшей от LXC. Данный файл наглядно показывает итоговые настройки, в том числе все его устройства, bind-mount и так далее.

/var/log/lxd/CONTAINER/forkexec.log
Данный файл содержит ошибки, поступающие с уровня LXC, когда он не смог выполнить команду. Это должно быть очень редко, так как LXD обрабатывает ошибки гораздо раньше.

/var/log/lxd/CONTAINER/forkstart.log
Данный файл содержит ошибки, поступающие с уровня LXC, когда он не смог запустить контейнер. Это должно быть очень редко, так как LXD обрабатывает ошибки гораздо раньше.

Журналы Checkpoint/Restore In Userspace (CRIU) для живой миграции

При использовании технологий живой миграции и мгновенных снимков дополнительно создаются журналы всякий раз когда CRIU создаёт или восстанавливает дамп. Ещё можно глянуть журналы в /var/log/lxd/CONTAINER/, которые датируются, чтобы легко можно было найти проблему из ваших последних попыток. В данных журналах более подробно пишется о ходе работы CRIU и с помощью данных журналов быстрее можно понять суть проблемы в работе миграции или создания снимков.

Отладочные сообщения LXD

Как было сказано выше, вы можете передать опцию -debug демону LXD. Альтернативно можно подключится, даже удалённо, к интерфейсу событий, чтобы увидеть нужные записи.

Для примера lxc init ubuntu:16.04 xen
lxd.log будет

INFO[02-24|18:14:09] Starting container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
INFO[02-24|18:14:10] Started container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000

lxc monitor -type=logging будет

metadata:
  context: {}
  level: dbug
  message: 'New events listener: 9b725741-ffe7-4bfc-8d3e-fe620fc6e00a'
timestamp: 2017-02-24T18:14:01.025989062-05:00
type: logging

metadata:
  context:
    ip: '@'
    method: GET
    url: /1.0
  level: dbug
  message: handling
timestamp: 2017-02-24T18:14:09.341283344-05:00
type: logging

metadata:
  context:
    driver: storage/zfs
  level: dbug
  message: StorageCoreInit
timestamp: 2017-02-24T18:14:09.341536477-05:00
type: logging

metadata:
  context:
    ip: '@'
    method: GET
    url: /1.0/containers/xen
  level: dbug
  message: handling
timestamp: 2017-02-24T18:14:09.347709394-05:00
type: logging

metadata:
  context:
    ip: '@'
    method: PUT
    url: /1.0/containers/xen/state
  level: dbug
  message: handling
timestamp: 2017-02-24T18:14:09.357046302-05:00
type: logging

metadata:
  context: {}
  level: dbug
  message: 'New task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:09.358387853-05:00
type: logging

metadata:
  context: {}
  level: dbug
  message: 'Started task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:09.358578599-05:00
type: logging

metadata:
  context:
    ip: '@'
    method: GET
    url: /1.0/operations/2e2cf904-c4c4-4693-881f-57897d602ad3/wait
  level: dbug
  message: handling
timestamp: 2017-02-24T18:14:09.366213106-05:00
type: logging

metadata:
  context:
    driver: storage/zfs
  level: dbug
  message: StoragePoolInit
timestamp: 2017-02-24T18:14:09.369636451-05:00
type: logging

metadata:
  context:
    driver: storage/zfs
  level: dbug
  message: StoragePoolCheck
timestamp: 2017-02-24T18:14:09.369771164-05:00
type: logging

metadata:
  context:
    container: xen
    driver: storage/zfs
  level: dbug
  message: ContainerMount
timestamp: 2017-02-24T18:14:09.424696767-05:00
type: logging

metadata:
  context:
    driver: storage/zfs
    name: xen
  level: dbug
  message: ContainerUmount
timestamp: 2017-02-24T18:14:09.432723719-05:00
type: logging

metadata:
  context:
    container: xen
    driver: storage/zfs
  level: dbug
  message: ContainerMount
timestamp: 2017-02-24T18:14:09.721067917-05:00
type: logging

metadata:
  context:
    action: start
    created: 2017-02-24 23:11:45 +0000 UTC
    ephemeral: "false"
    name: xen
    stateful: "false"
    used: 1970-01-01 00:00:00 +0000 UTC
  level: info
  message: Starting container
timestamp: 2017-02-24T18:14:09.749808518-05:00
type: logging

metadata:
  context:
    ip: '@'
    method: GET
    url: /1.0
  level: dbug
  message: handling
timestamp: 2017-02-24T18:14:09.792551375-05:00
type: logging

metadata:
  context:
    driver: storage/zfs
  level: dbug
  message: StorageCoreInit
timestamp: 2017-02-24T18:14:09.792961032-05:00
type: logging

metadata:
  context:
    ip: '@'
    method: GET
    url: /internal/containers/23/onstart
  level: dbug
  message: handling
timestamp: 2017-02-24T18:14:09.800803501-05:00
type: logging

metadata:
  context:
    driver: storage/zfs
  level: dbug
  message: StoragePoolInit
timestamp: 2017-02-24T18:14:09.803190248-05:00
type: logging

metadata:
  context:
    driver: storage/zfs
  level: dbug
  message: StoragePoolCheck
timestamp: 2017-02-24T18:14:09.803251188-05:00
type: logging

metadata:
  context:
    container: xen
    driver: storage/zfs
  level: dbug
  message: ContainerMount
timestamp: 2017-02-24T18:14:09.803306055-05:00
type: logging

metadata:
  context: {}
  level: dbug
  message: 'Scheduler: container xen started: re-balancing'
timestamp: 2017-02-24T18:14:09.965080432-05:00
type: logging

metadata:
  context:
    action: start
    created: 2017-02-24 23:11:45 +0000 UTC
    ephemeral: "false"
    name: xen
    stateful: "false"
    used: 1970-01-01 00:00:00 +0000 UTC
  level: info
  message: Started container
timestamp: 2017-02-24T18:14:10.162965059-05:00
type: logging

metadata:
  context: {}
  level: dbug
  message: 'Success for task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
timestamp: 2017-02-24T18:14:10.163072893-05:00
type: logging

Как видно в примере, формат lxc monitor является многострочным в отличии от файла журнала. Но что более важно, вы видите все записи level: dbug

Куда отправлять отчёты?

Ошибки LXD

Лучшее место для отправки отчётов про LXD это lxd issues апстрима. Убедитесь в том, что вы заполнили всё в шаблоне ошибки, что сэкономить всем время для воспроизведения вашего окружения.

Ошибки Ubuntu

Если обнаружена ошибка в самом пакете для Ubuntu, проблема в установке/обновлении/удалении или проблема в инициализационных скриптах LXD, то лучше запулить отчёт на Launchpad. Команда ubuntu-bug lxd автоматически соберёт нужные журналы и информацию о проблемном пакете и отправит, создав отчёт о баге.

Ошибки CRIU

Ошибки, связанные с технологией CRIU, отправляйте так же на Launchpad - ubuntu-bug criu
Обратите внимание, что использование CRIU через LXD пока считается beta функцией и, если вы не готовы платить Canonical за поддержку, то может пройти достаточно времени, когда вашим отчётом займутся.

Вклад в LXD

LXD написан на Go и хостится на Github. Приветствуется любой посильный вклад. Нет Contributor licence agreement (CLA) или подобного юридического соглашения. Используется обычное Developer Certificate of Ownership (Signed-off-by: line). Есть ряд запрашиваемых фичей, перечисленных в выше описываемом issue tracker. Это хорошее место для старта новичка, но лучше заранее подать заявку, перед работой над кодом, чтобы остальные были в курсе, что начата работа и они могли бы дать ценные советы.

Сборка LXD из исходников

Самые актуальные инструкции от апстрима можно найти в building-from-source

Рекомендуется делать rebase как можно чаще, так как изменения объединяют довольно регулярно.

Запуск набора тестов

LXD поставляется с 2 наборами тестов: юнит и интеграционные. Всё запустить можно командой sudo -E make check
Запустить только unit тесты - sudo -E go test ./...
Интеграционные - cd test && sudo -E ./main.sh

Есть переменные окружения для изменения поведения тестов:

• LXD_BACKEND: Одно из btrfs, dir, lvm или zfs (по умолчанию dir). Все тесты коснутся конкретного бэкенда хранилища LXD.
• LXD_CONCURRENT: true или false (по умолчанию false). Включаются дополнительные тесты на параллелизм (concurrency tests).
• LXD_DEBUG: true или false (по умолчанию false). Журналируются все команды shell и команды LXD производятся в режиме debug.
• LXD_INSPECT: true или false (по умолчанию false). Набор тестов при ошибке останавливается, чтобы вы могли осмотреть текущее окружение.
• LXD_LOGS: каталог для всех LXD журналов (по умолчанию "").
• LXD_OFFLINE: true или false (по умолчанию false). Запрещает любой тест, связанный с внешним сетевым обменом.
• LXD_TEST_IMAGE: путь к LXD образу (по умолчанию ""). Позволяет использовать свой тестовый образ вместо дефолтного, минимального образа busybox.
• LXD_TMPFS: true или false (по умолчанию false). Запуск тестов в tmpfs, что займёт немного памяти, но позволит значительно ускорить тесты.
• LXD_VERBOSE: true или false (по умолчанию false). Это такой менее экстремальный LXD_DEBUG. Команды shell продолжают журналироваться, но опция -debug не передаётся командам LXC, а LXD работает с параметром -verbose.

Если чего-то будет не хватать для тестов, то до запуска вам будет об этом сообщено. Тесты на мощном железе могут быть сделаны менее чем за 10 минут.

Отправка ваших изменений

До того как сделать запрос на включение сделанных вами изменений (pull request), ответьте согласием что:

• Вашу ветку можно объединить (rebase) с веткой апстрима.
• Все ваши коммиты обладают строкой Signed-off-by: First Last <email>.
• Удалён любой временный код для отладки, который вы использовали.
• Вы склеили связанные коммиты (squashed related commits), чтобы вашу ветку легко было читать.
• Ваши изменения проходят все тесты.

Если вышеописанное сделано, то делайте запрос. Система непрерывной интеграции Jenkins проверит коммиты, создаст тестовые сборки для MacOS и Windows и если всё хорошо, то апстримом будет инициирован полный тест с помощью Jenkins вашей ветки и всех бэкендов хранилищ, 32 и 64 бита и всех версий Go. Обычно это занимает около 1 часа. Если все тесты будут пройдены, ваша ветка будет объединена с master, и ваш код попадёт в будущий LXD релиз. Если ваши изменения подходят к стабильной ветке LXD stable-2.0, то апстрим их бэкпортирует в неё.

Итог

Серия закончилась и надеюсь вам стало чуточку понятнее, что такое LXD и что он умеет. Серия статей часто подразумевала стабильную LTS версию LXD (2.0.x), но есть так же ежемесячные релизы для тех, кто ждёт последних новинок.

Некоторые статьи, не в рамках данного цикла, вы можете найти в оглавлении LXD 2.0.

Дополнительная информация

LXC используется как низкоуровневый слой - цикл статей про LXC.
LXD, который умеет гораздо больше и упрощает работу с контейнерами, использует LXC под капотом - цикл статей про LXD.
Предыдущая статья LXD 2.0: LXD и OpenStack [11/12].

Стефан Грабер (Stéphane Graber) о LXD.

OpenStack Foundation использует LXD для контейнеризации linux систем.

Дата последней правки: 2023-12-27 12:02:22