華文網

LXD 2.0 系列（十二）：調試，及給 LXD 做貢獻

如果你想自己解決問題或通過實現你需要的功能來説明改善LXD怎麼辦？如何構建，

測試和貢獻 LXD 代碼庫？ -- Stéphane Graber

本文導航

-介紹 …… 00%

-調試 LXD 並填寫 bug 報告 …… 10%

-LXD 日誌檔 …… 10%

-CRIU 日誌 (對於即時遷移) …… 16%

-LXD 調試消息 …… 19%

-如何報告 bug …… 52%

-LXD 的 bug …… 52%

-Ubuntu 的 bug …… 54%

-CRIU 的 bug …… 56%

-貢獻給 LXD …… 58%

-從源碼源碼構建 LXD …… 62%

-運行測試套件 …… 64%

-發送你的分支 …… 82%

-總結 …… 89%

-額外的資訊 …… 92%

編譯自： https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/

作者： Stéphane Graber

譯者： geekpi

介紹

終於要結束了！這個大約一年前開始的這系列文章的最後一篇博文。

LXD 入門[1]

安裝與配置[2]

你的第一個 LXD 容器[3]

資源控制[4]

鏡像管理[5]

遠端主機及容器遷移[6]

LXD 中的 Docker[7]

LXD 中的 LXD[8]

即時遷移[9]

LXD 和 Juju[10]

LXD 和 OpenStack[11]

調試，及給 LXD 做貢獻[12]

如果你從一開始就關注了這個系列，你應該已經使用了 LXD 相當長的時間了，並且非常熟悉它的日常操作和功能。

但如果出現問題怎麼辦？你可以做什麼來自己跟蹤問題？如果你不能，你應該記錄什麼資訊，以便上游可以跟蹤問題？

如果你想自己解決問題或通過實現你需要的功能來説明改善LXD怎麼辦？如何構建，測試和貢獻 LXD 代碼庫？

調試 LXD 並填寫 bug 報告LXD 日誌檔

/var/log/lxd/lxd.log：

這是 LXD 日誌的主文件。為了避免它快速充滿你的磁片，預設只會記錄 INFO、WARNING 或者 ERROR 級別的日誌。你可以在 LXD 守護進程中使用 –debug 改變其行為。

/var/log/lxd/CONTAINER/lxc.conf：

每當你啟動容器時，此檔將更新為傳遞給 LXC 的配置。

這裡會展示容器將如何配置，包括其所有的設備、綁定掛載等等。

/var/log/lxd/CONTAINER/forkexec.log：

這個檔包含 LXC 命令執行失敗時產生的錯誤。這個情況是非常罕見的，因為 LXD 通常會在發生之前處理大多數錯誤。

/var/log/lxd/CONTAINER/forkstart.log：

這個檔包含 LXC 在啟動容器時的錯誤資訊。含 LXC 命令執行失敗時產生的錯誤。

CRIU 日誌 (對於即時遷移)

如果使用 CRIU 進行容器即時遷移或即時快照，則每次生成 CRIU 轉儲或恢復轉儲時都會記錄額外的日誌檔。

這些日誌也可以在 /var/log/lxd/CONTAINER/ 中找到，並且有時間戳記，以便你可以找到與你最近的操作所匹配的那些日誌。它們包含 CRIU 轉儲和恢復的所有內容的詳細記錄，並且比典型的遷移/快照錯誤消息更容器理解。

LXD 調試消息

如上所述，你可以使用 -debug 選項將守護進程切換為執行調試日誌記錄。另一種方法是連接到守護進程的事件介面，它將顯示所有日誌條目，而不管配置的日誌級別（即使是遠端工作）。

舉例說，對於 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 條目。

如何報告 bugLXD 的 bug

最好報告 bug 的地方是 https://github.com/lxc/lxd/issues。確保完整填寫了 bug 報告範本中的內容，

這些資訊可以節省我們我們時間來複現環境。

Ubuntu 的 bug

如果你發現 Ubuntu 包本身有問題，無法安裝、升級或刪除。或者遇到 LXD init 腳本的問題。報告此類錯誤的最好是在 Launchpad 上。

在 Ubuntu 系統上，你可以使用：ubuntu-bug lxd ，它將自動包括一些日誌檔和包資訊供我們查看。

CRIU 的 bug

與 CRIU 相關的 Bug，你可以通過 CRIU 的錯誤輸出發現，你應該在 Launchpad 上報告這些：ubuntu-bug criu

請注意，通過 LXD 使用 CRIU 屬於測試版功能，除非你願意通過 Canonical 的支持合同付費支援，要麼可能需要一段時間才能查看你的錯誤報告。

貢獻給 LXD

LXD 用 Go[13] 寫成並託管在 Github[14]。我們歡迎任外部的貢獻。為 LXD 貢獻不需要 CLA 或類似的法律協議簽署，只是通常的開發者所有權證書（Signed-off-by: 行）。

在我們的問題追蹤器工具中，我們列有許多潛在的功能需求，新的貢獻者可以以此作為良好的起點。通常最好在開始處理代碼先發出 issue，這樣每個人都知道你正在做這項工作，以便我們可以提供一些早期回饋。

從源碼源碼構建 LXD

這裡有上游的維護說明：https://github.com/lxc/lxd#building-from-source

你需要在 Github 上 fork 上游倉庫，然後將你的更改推送到你的分支。我們建議每天 rebase 上游的 LXD，因為我們傾向於定期合併更改。

運行測試套件

LXD 維護了兩套測試集，單元測試和集成測試。你可以用下面的命令測試所有：

sudo -E make check

要只運行單元測試，使用：

sudo -E go test ./...

要運行集成測試，使用：

cd test

sudo -E ./main.sh

後者支援相當多的環境變數來測試各種存儲後端、禁用網路測試、使用 ramdisk 或只是調整日誌輸出。其中一些是：

LXD_BACKEND：btrfs、dir、lvm 或 zfs” 之一（默認為 dir）

運行 LXD 存儲驅動程式相關的所有測試。

LXD_CONCURRENT：true 或 false（默認為 false）

這啟用一些額外的併發測試。

LXD_DEBUG：true 或 false（預設為 false）

記錄所有 shell 命令，並在調試模式下運行所有 LXD 命令。

LXD_INSPECT：true 或 false（預設為 false）

測試程式會在故障時掛起，以便你可以檢查環境。

LXD_LOGS：將所有 LXD 日誌檔轉儲到的目錄（預設為 “”）

所有生成的 LXD 守護進程的 logs 目錄將被複製到此路徑。

LXD_OFFLINE：true 或 false（默認為 false）

禁用任何依賴於外部網路連接的測試。

LXD_TEST_IMAGE： unified 格式的 LXD 鏡像的路徑（預設為 “”）

可以使用自訂測試鏡像，而不是默認的最小 busybox 鏡像。

LXD_TMPFS：true 或 false（默認為 false）

在 tmpfs 安裝中運行整個測試套件，這會使用相當多的記憶體，但會使測試速度明顯更快。

LXD_VERBOSE：true 或 false（默認為 false）

不太極端的 LXD_DEBUG 版本。shell 命令仍然會記錄，但 -debug 不會傳遞給 LXC 命令，LXD 守護進程只能使用 -verbose 運行。

測試程式將在實際運行之前提醒你任何缺失的依賴項。在相當快的機器上運行該測試可在 10 分鐘內完成。

發送你的分支

發送拉取請求（PR）之前，你需要確認：

你已經 rebase 了上游分支

你的所有提交資訊都包括 Signed-off-by: First Last 這行

已刪除任何你的臨時調試代碼

你已經將相關的提交 squash 在一起，以保持你的分支容易審查

單元和集成測試全部通過

一切完成後，在 Github 上發起一個拉取請求。我們的 Jenkins[15] 將驗證提交是否全部有 signed-off，在 MacOS 和 Windows 上的測試將自動執行，如果看起來不錯，我們將觸發一個完整的 Jenkins 測試，它將在所有存儲後端、32 位和 64 位以及我們關心的所有 Go 版本上測試你的分支。

假設我們有人觸發了 Jenkins，這通常需要不到一個小時的時間。

一旦所有測試完成，我們對代碼本身感到滿意，你的分支將會被合併，你的代碼會出現在下一個 LXD 發佈中。如果更改適用於 LXD stable-2.0 分支，我們將為你向後移植。

總結

我希望這個系列的博客文章有助於你瞭解什麼是 LXD，以及它可以做什麼！

本系列的範圍僅限於 LXD（2.0.x），但我們也為那些想要最新功能的用戶提供每月功能版本。你可以找到一些其他涵蓋了原來的 LXD 2.0系列文章[16]中列出的功能的博客文章。

額外的信息

LXD 的主站在： https://linuxcontainers.org/lxd

LXD 的 GitHub 開發倉庫： https://github.com/lxc/lxd

LXD 的郵寄清單： https://lists.linuxcontainers.org

LXD 的 IRC 頻道：#lxcontainers on irc.freenode.net

線上嘗試 LXD： https://linuxcontainers.org/lxd/try-it

作者簡介：我是 Stéphane Graber。我是 LXC 和 LXD 專案的領導者，目前在加拿大魁北克蒙特利爾的家所在的 Canonical 有限公司擔任 LXD 的技術主管。

via: https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/

作者：Stéphane Graber[17] 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

[1]: LXD 入門 - https://linux.cn/article-7618-1.html

[2]: 安裝與配置 - https://linux.cn/article-7687-1.html

[3]: 你的第一個 LXD 容器 - https://linux.cn/article-7706-1.html

[4]: 資源控制 - https://linux.cn/article-8072-1.html

[5]: 鏡像管理 - https://linux.cn/article-8107-1.html

[6]: 遠端主機及容器遷移 - https://linux.cn/article-8169-1.html

[7]: LXD 中的 Docker - https://linux.cn/article-8235-1.html

[8]: LXD 中的 LXD - https://linux.cn/article-8257-1.html

[9]: 即時遷移 - https://linux.cn/article-8263-1.html

[10]: LXD 和 Juju - https://linux.cn/article-8273-1.html

[11]: LXD 和 OpenStack - https://linux.cn/article-8274-1.html

[12]: 調試，及給 LXD 做貢獻 - https://linux.cn/article-8282-1.html

[13]: Go - https://golang.org/

[14]: 託管在 Github - https://github.com/lxc/lxd

[15]: Jenkins - https://jenkins.linuxcontainers.org/

[16]: LXD 2.0系列文章 - https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/

[17]: Stéphane Graber - https://stgraber.org/author/stgraber/

要麼可能需要一段時間才能查看你的錯誤報告。

貢獻給 LXD

LXD 用 Go[13] 寫成並託管在 Github[14]。我們歡迎任外部的貢獻。為 LXD 貢獻不需要 CLA 或類似的法律協議簽署，只是通常的開發者所有權證書（Signed-off-by: 行）。

在我們的問題追蹤器工具中，我們列有許多潛在的功能需求，新的貢獻者可以以此作為良好的起點。通常最好在開始處理代碼先發出 issue，這樣每個人都知道你正在做這項工作，以便我們可以提供一些早期回饋。

從源碼源碼構建 LXD

這裡有上游的維護說明：https://github.com/lxc/lxd#building-from-source

你需要在 Github 上 fork 上游倉庫，然後將你的更改推送到你的分支。我們建議每天 rebase 上游的 LXD，因為我們傾向於定期合併更改。

運行測試套件

LXD 維護了兩套測試集，單元測試和集成測試。你可以用下面的命令測試所有：

sudo -E make check

要只運行單元測試，使用：

sudo -E go test ./...

要運行集成測試，使用：

cd test

sudo -E ./main.sh

後者支援相當多的環境變數來測試各種存儲後端、禁用網路測試、使用 ramdisk 或只是調整日誌輸出。其中一些是：

LXD_BACKEND：btrfs、dir、lvm 或 zfs” 之一（默認為 dir）

運行 LXD 存儲驅動程式相關的所有測試。

LXD_CONCURRENT：true 或 false（默認為 false）

這啟用一些額外的併發測試。

LXD_DEBUG：true 或 false（預設為 false）

記錄所有 shell 命令，並在調試模式下運行所有 LXD 命令。

LXD_INSPECT：true 或 false（預設為 false）

測試程式會在故障時掛起，以便你可以檢查環境。

LXD_LOGS：將所有 LXD 日誌檔轉儲到的目錄（預設為 “”）

所有生成的 LXD 守護進程的 logs 目錄將被複製到此路徑。

LXD_OFFLINE：true 或 false（默認為 false）

禁用任何依賴於外部網路連接的測試。

LXD_TEST_IMAGE： unified 格式的 LXD 鏡像的路徑（預設為 “”）

可以使用自訂測試鏡像，而不是默認的最小 busybox 鏡像。

LXD_TMPFS：true 或 false（默認為 false）

在 tmpfs 安裝中運行整個測試套件，這會使用相當多的記憶體，但會使測試速度明顯更快。

LXD_VERBOSE：true 或 false（默認為 false）

不太極端的 LXD_DEBUG 版本。shell 命令仍然會記錄，但 -debug 不會傳遞給 LXC 命令，LXD 守護進程只能使用 -verbose 運行。

測試程式將在實際運行之前提醒你任何缺失的依賴項。在相當快的機器上運行該測試可在 10 分鐘內完成。

發送你的分支

發送拉取請求（PR）之前，你需要確認：

你已經 rebase 了上游分支

你的所有提交資訊都包括 Signed-off-by: First Last 這行

已刪除任何你的臨時調試代碼

你已經將相關的提交 squash 在一起，以保持你的分支容易審查

單元和集成測試全部通過

一切完成後，在 Github 上發起一個拉取請求。我們的 Jenkins[15] 將驗證提交是否全部有 signed-off，在 MacOS 和 Windows 上的測試將自動執行，如果看起來不錯，我們將觸發一個完整的 Jenkins 測試，它將在所有存儲後端、32 位和 64 位以及我們關心的所有 Go 版本上測試你的分支。

假設我們有人觸發了 Jenkins，這通常需要不到一個小時的時間。

一旦所有測試完成，我們對代碼本身感到滿意，你的分支將會被合併，你的代碼會出現在下一個 LXD 發佈中。如果更改適用於 LXD stable-2.0 分支，我們將為你向後移植。

總結

我希望這個系列的博客文章有助於你瞭解什麼是 LXD，以及它可以做什麼！

本系列的範圍僅限於 LXD（2.0.x），但我們也為那些想要最新功能的用戶提供每月功能版本。你可以找到一些其他涵蓋了原來的 LXD 2.0系列文章[16]中列出的功能的博客文章。

額外的信息

LXD 的主站在： https://linuxcontainers.org/lxd

LXD 的 GitHub 開發倉庫： https://github.com/lxc/lxd

LXD 的郵寄清單： https://lists.linuxcontainers.org

LXD 的 IRC 頻道：#lxcontainers on irc.freenode.net

線上嘗試 LXD： https://linuxcontainers.org/lxd/try-it

作者簡介：我是 Stéphane Graber。我是 LXC 和 LXD 專案的領導者，目前在加拿大魁北克蒙特利爾的家所在的 Canonical 有限公司擔任 LXD 的技術主管。

via: https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/

作者：Stéphane Graber[17] 譯者：geekpi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

[1]: LXD 入門 - https://linux.cn/article-7618-1.html

[2]: 安裝與配置 - https://linux.cn/article-7687-1.html

[3]: 你的第一個 LXD 容器 - https://linux.cn/article-7706-1.html

[4]: 資源控制 - https://linux.cn/article-8072-1.html

[5]: 鏡像管理 - https://linux.cn/article-8107-1.html

[6]: 遠端主機及容器遷移 - https://linux.cn/article-8169-1.html

[7]: LXD 中的 Docker - https://linux.cn/article-8235-1.html

[8]: LXD 中的 LXD - https://linux.cn/article-8257-1.html

[9]: 即時遷移 - https://linux.cn/article-8263-1.html

[10]: LXD 和 Juju - https://linux.cn/article-8273-1.html

[11]: LXD 和 OpenStack - https://linux.cn/article-8274-1.html

[12]: 調試，及給 LXD 做貢獻 - https://linux.cn/article-8282-1.html

[13]: Go - https://golang.org/

[14]: 託管在 Github - https://github.com/lxc/lxd

[15]: Jenkins - https://jenkins.linuxcontainers.org/

[16]: LXD 2.0系列文章 - https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/

[17]: Stéphane Graber - https://stgraber.org/author/stgraber/