document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-23 21:20:42 +08:00
Code Issues Packages Projects Releases Wiki Activity

translated

Browse Source
This commit is contained in:
geekpi 2017-03-08 11:34:25 +08:00
parent c1c0b2583b
commit 616bf91c54
2 changed files with 394 additions and 403 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

403
sources/tech/20170227 Part 12 - LXD 2.0 Debugging and contributing to LXD .md
View File

@ -1,403 +0,0 @@
translating---geekpi
# LXD 2.0: Debugging and contributing to LXD [12/12]
![LXD logo](https://linuxcontainers.org/static/img/containers.png)
### Introduction
This is finally it! The last blog post in this [series of 12][3] that started almost a year ago.
If you followed the series from the beginning, you should have been using LXD for quite a bit of time now and be pretty familiar with its day to day operation and capabilities.
But what if something goes wrong? What can you do to track down the problem yourself? And if you can’t, what information should you record so that upstream can track down the problem?
And what if you want to fix issues yourself or help improve LXD by implementing the features you need? How do you build, test and contribute to the LXD code base?
## Debugging LXD & filing bug reports
### LXD log files
#### /var/log/lxd/lxd.log
This is the main LXD log file. To avoid filling up your disk very quickly, only log messages marked as INFO, WARNING or ERROR are recorded there by default. You can change that behavior by passing “–debug” to the LXD daemon.
#### /var/log/lxd/CONTAINER/lxc.conf
Whenever you start a container, this file is updated with the configuration that’s passed to LXC.
This shows exactly how the container will be configured, including all its devices, bind-mounts, …
#### /var/log/lxd/CONTAINER/forkexec.log
This file will contain errors coming from LXC when failing to execute a command.
It’s extremely rare for anything to end up in there as LXD usually handles errors much before that.
#### /var/log/lxd/CONTAINER/forkstart.log
This file will contain errors coming from LXC when starting the container.
It’s extremely rare for anything to end up in there as LXD usually handles errors much before that.
### CRIU logs (for live migration)
If you are using CRIU for container live migration or live snapshotting there are additional log files recorded every time a CRIU dump is generated or a dump is restored.
Those logs can also be found in /var/log/lxd/CONTAINER/ and are timestamped so that you can find whichever matches your most recent attempt. They will contain a detailed record of everything that’s dumped and restored by CRIU and are far better for understanding a failure than the typical migration/snapshot error message.
### LXD debug messages
As mentioned above, you can switch the daemon to doing debug logging with the –debug option.
An alternative to that is to connect to the daemon’s event interface which will show you all log entries, regardless of the configured log level (even works remotely).
An example for “lxc init ubuntu:16.04 xen” would be:
**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
```
The format from “lxc monitor” is a bit different from what you’d get in a log file where each entry is condense into a single line, but more importantly you see all those “level: dbug” entries
## Where to report bugs
### LXD bugs
The best place to report LXD bugs is upstream at [https://github.com/lxc/lxd/issues][4].
Make sure to fill in everything in the bug reporting template as that information saves us a lot of back and forth to reproduce your environment.
### Ubuntu bugs
If you find a problem with the Ubuntu package itself, failing to install, upgrade or remove. Or run into issues with the LXD init scripts. The best place to report such bugs is on Launchpad.
On an Ubuntu system, you can do so with: ubuntu-bug lxd
This will automatically include a number of log files and package information for us to look at.
### CRIU bugs
Bugs that are related to CRIU which you can spot by the usually pretty visible CRIU error output should be reported on Launchpad with: ubuntu-bug criu
Do note that the use of CRIU through LXD is considered to be a beta feature and unless you are willing to pay for support through a support contract with Canonical, it may take a while before we get to look at your bug report.
## Contributing to LXD
LXD is written in [Go][5] and [hosted on Github][6].
We welcome external contributions of any size. There is no CLA or similar legal agreement to sign to contribute to LXD, just the usual Developer Certificate of Ownership (Signed-off-by: line).
We have a number of potential features listed on our issue tracker that can make good starting points for new contributors. It’s usually best to first file an issue before starting to work on code, just so everyone knows that you’re doing that work and so we can give some early feedback.
### Building LXD from source
Upstream maintains up to date instructions here: [https://github.com/lxc/lxd#building-from-source][7]
You’ll want to fork the upstream repository on Github and then push your changes to your branch. We recommend rebasing on upstream LXD daily as we do tend to merge changes pretty regularly.
### Running the testsuite
LXD maintains two sets of tests. Unit tests and integration tests. You can run all of them with:
```
sudo -E make check
```
To run the unit tests only, use:
```
sudo -E go test ./...
```
To run the integration tests, use:
```
cd test
sudo -E ./main.sh
```
That latter one supports quite a number of environment variables to test various storage backends, disable network tests, use a ramdisk or just tweak log output. Some of those are:
* LXD_BACKEND: One of “btrfs”, “dir”, “lvm” or “zfs” (defaults to “dir”)
Lets your run the whole testsuite with any of the LXD storage drivers.
* LXD_CONCURRENT: “true” or “false” (defaults to “false”)
This enables a few extra concurrency tests.
* LXD_DEBUG: “true” or “false” (defaults to “false”)
This will log all shell commands and run all LXD commands in debug mode.
* LXD_INSPECT: “true” or “false” (defaults to “false”)
This will cause the testsuite to hang on failure so you can inspect the environment.
* LXD_LOGS: A directory to dump all LXD log files into (defaults to “”)
The “logs” directory of all spawned LXD daemons will be copied over to this path.
* LXD_OFFLINE: “true” or “false” (defaults to “false”)
Disables any test which relies on outside network connectivity.
* LXD_TEST_IMAGE: path to a LXD image in the unified format (defaults to “”)
Lets you use a custom test image rather than the default minimal busybox image.
* LXD_TMPFS: “true” or “false” (defaults to “false”)
Runs the whole testsuite within a “tmpfs” mount, this can use quite a bit of memory but makes the testsuite significantly faster.
* LXD_VERBOSE: “true” or “false” (defaults to “false”)
A less extreme version of LXD_DEBUG. Shell commands are still logged but –debug isn’t passed to the LXC commands and the LXD daemon only runs with –verbose.
The testsuite will alert you to any missing dependency before it actually runs. A test run on a reasonably fast machine can be done under 10 minutes.
### Sending your branch
Before sending a pull request, you’ll want to confirm that:
* Your branch has been rebased on the upstream branch
* All your commits messages include the “Signed-off-by: First Last <email>” line
* You’ve removed any temporary debugging code you may have used
* You’ve squashed related commits together to keep your branch easily reviewable
* The unit and integration tests all pass
Once that’s all done, open a pull request on Github. Our [Jenkins][8] will validate that the commits are all signed-off, a test build on MacOS and Windows will automatically be performed and if things look good, we’ll trigger a full Jenkins test run that will test your branch on all storage backends, 32bit and 64bit and all the Go versions we care about.
This typically takes less than an hour to happen, assuming one of us is around to trigger Jenkins.
Once all the tests are done and we’re happy with the code itself, your branch will be merged into master and your code will be in the next LXD feature release. If the changes are suitable for the LXD stable-2.0 branch, we’ll backport them for you.
# Conclusion
I hope this series of blog post has been helpful in understanding what LXD is and what it can do!
This series’ scope was limited to the LTS version of LXD (2.0.x) but we also do monthly feature releases for those who want the latest features. You can find a few other blog posts covering such features listed in the original [LXD 2.0 series post][9].
# Extra information
The main LXD website is at: [https://linuxcontainers.org/lxd
][10]Development happens on Github at: [https://github.com/lxc/lxd][11]
Mailing-list support happens on: [https://lists.linuxcontainers.org][12]
IRC support happens in: #lxcontainers on irc.freenode.net
Try LXD online: [https://linuxcontainers.org/lxd/try-it][13]
--------------------------------------------------------------------------------
via: https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/
作者：[Stéphane Graber ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://stgraber.org/author/stgraber/
[1]:https://stgraber.org/author/stgraber/
[2]:https://www.stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
[3]:https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
[4]:https://github.com/lxc/lxd/issues
[5]:https://golang.org/
[6]:https://github.com/lxc/lxd
[7]:https://github.com/lxc/lxd#building-from-source
[8]:https://jenkins.linuxcontainers.org/
[9]:https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
[10]:https://linuxcontainers.org/lxd
[11]:https://github.com/lxc/lxd
[12]:https://lists.linuxcontainers.org/
[13]:https://linuxcontainers.org/lxd/try-it
[14]:https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/

394
translated/tech/LXD/20170227 Part 12 - LXD 2.0 Debugging and contributing to LXD .md Normal file
View File

@ -0,0 +1,394 @@
LXD 2.0 系列（十二）：调试并给 LXD 做贡献 [12/12]
![LXD logo](https://linuxcontainers.org/static/img/containers.png)
### 介绍
终于要结束了！这个大约一年前开始的[这系列文章][3]的最后一篇博文。
如果你从一开始就关注了这个系列，你应该已经使用了 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 在启动容器时的错误信息。这个情况是非常罕见的，因为 LXD 通常会在发生之前处理错误。
### CRIU 日志 (对于实时迁移)
如果使用 CRIU 进行容器实时迁移或实时快照，则每次生成 CRIU 转储或恢复转储时都会记录额外的日志文件。
这些日志也可以在 /var/log/lxd/CONTAINER/ 中找到，并且有时间戳，以便你可以找到与你最近的尝试匹配的那些日志。它们包含 CRIU 转储和恢复的所有内容的详细记录，并且比典型的迁移/快照错误消息更容器理解。
### LXD debug messages
如上所述，你可以使用 -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” 条目。
## 如何报告 bug
### LXD bugs
最好报告 bug 的地方是 [https://github.com/lxc/lxd/issues][4]。确保完整填写了 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][5] 写成并[托管在 Github][6]。我们欢迎任外部的贡献。为 LXD 贡献不需要 CLA 或类似的法律协议签署，只是通常的开发者所有权证书（Signed-off-by: line）。
在我们的问题追踪器工具中，我们有许多潜在的功能，可以为新的贡献者做出良好的起点。通常最好在开始处理代码先提出问题，这样每个人都知道你正在做这项工作，所以我们可以提供一些早期反馈。
### 从源码源码构建 LXD
这里有上流的维护说明：[https://github.com/lxc/lxd#building-from-source][7]
你需要在 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：以统一格式（默认为“”）的 LXD 镜像的路径
  可以使用自定义测试镜像，而不是默认的最小 busybox 镜像。
* LXD_TMPFS：“true” 或 “false”（默认为“false”）
  在 “tmpfs” 安装中运行整个测试套件，这会使用相当多的内存，但会使测试速度明显更快。
* LXD_VERBOSE：“true” 或 “false”（默认为“false”）
  LXD_DEBUG 不太极端的版本。shell 命令仍然会记录，但 -debug 不会传递给 LXC 命令，LXD 守护进程只能使用 -verbose 运行。
测试程序将在实际运行之前提醒你任何丢失的依赖。在相当快的机器上运行测试可在 10 分钟内完成。
### 发送你的分支
发送 pull 请求之前，你需要确认：
* 你已经 rebase 了上游分支
* 你的所有提交信息都包括 “Signed-off-by: First Last <email>” 这行
* 已删除任何你的临时调试代码
* 你已经将相关的提交 squash 在一起，以保持你的分支容易审查
* 单元和集成测试全部通过
一切完成后，在 Github 上发起一个 pull 请求。我们的 [Jenkins][8] 将验证提交是否全部签署，在 MacOS 和 Windows 上的测试将自动执行，如果看起来不错，我们将触发一个完整的 Jenkins 测试，它将测试你的分支所有存储后端、32 位和 64 位以及我们关心的所有 Go 版本。
假设我们有一个人要触发 Jenkins，这通常需要不到一个小时的时间。
一旦所有测试完成，我们对代码本身感到满意，你的分支将会被合并，你的代码会在下一个 LXD 发布中。如果更改适用于 LXD stable-2.0 分支，我们将为你向后移植。
# 总结
我希望这个系列的博客文章有助于你了解什么是LXD，以及它可以做什么！
本系列的范围仅限于 LXD（2.0.x），但我们也为那些想要最新功能的用户提供每月功能版本。你可以找到一些其他涵盖原始[LXD 2.0系列文章][9]中列出的功能的博客文章。
# 额外的信息
LXD 的主站在： [https://linuxcontainers.org/lxd][10]
LXD 的 GitHub 开发仓库： [https://github.com/lxc/lxd][11]
LXD 的邮件列表： [https://lists.linuxcontainers.org][12]
LXD 的 IRC 频道：#lxcontainers on irc.freenode.net
在线尝试 LXD： [https://linuxcontainers.org/lxd/try-it][13]
--------------------------------------------------------------------------------
via: https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/
作者：[Stéphane Graber ][a]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://stgraber.org/author/stgraber/
[1]:https://stgraber.org/author/stgraber/
[2]:https://www.stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
[3]:https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
[4]:https://github.com/lxc/lxd/issues
[5]:https://golang.org/
[6]:https://github.com/lxc/lxd
[7]:https://github.com/lxc/lxd#building-from-source
[8]:https://jenkins.linuxcontainers.org/
[9]:https://stgraber.org/2016/03/11/lxd-2-0-blog-post-series-012/
[10]:https://linuxcontainers.org/lxd
[11]:https://github.com/lxc/lxd
[12]:https://lists.linuxcontainers.org/
[13]:https://linuxcontainers.org/lxd/try-it
[14]:https://stgraber.org/2017/02/27/lxd-2-0-debugging-and-contributing-to-lxd-1212/