YaST Squad Sprint 62

Sprint 总结

Jenkins 在 GitHub pull request 中进行评论
Intel Rapid Start Technology 实现更好的休眠
SLE-12 中一致的存储方案
分区程序：设计其充分利用的 UI
分区程序：将整个磁盘作为软件 MD RAID 的成员
分区程序：更好地解释异常情况
一些 bug 修复示例

改进 Jenkins 集成

在 GitHub 上合并 pull request 后，我们的 Jenkins 作业经常因为某些原因而失败。由于 Jenkins 应该将更改提交到构建服务，因此如果没人注意到失败，Git 中的修复程序就不会发布在 RPM 包中。这有点令人困惑，因为我们在 Bugzilla 中关闭了一个 bug，但修复程序在任何地方都不可用。

为了避免这种情况，我们添加了一个包装脚本，它运行原始 Jenkins 命令（在本例中为 rake osc:sr），并将结果作为评论写入 GitHub 上相应的 pull request。如果创建了提交请求，它还会添加指向该请求的链接。

现在，您应该在合并 pull request 后保持 pull request 页面打开，并等待 Jenkins 状态结果。如果由于某种原因失败，请尝试修复它或在 IRC 或 YaST 邮件列表中寻求帮助。

注意：此自动化仅适用于处于积极开发中的代码分支以及分配了 Jenkins 作业的软件包（大多数 YaST 软件包都有）。

Intel Rapid Start Technology 支持

Intel Rapid Start Technology 允许使用快速磁盘（SSD）进行休眠到 RAM，以节省能源。其想法是，在经过一段时间后，RAM 的内容将被移动到 SSD，以便系统可以关闭电源。通电时，RAM 将被读回。所以它就像是动态地将休眠到 RAM 更改为休眠到快速磁盘。

这项技术需要安装程序做什么？它需要自己的专用分区来存储 RAM 的内容。为了支持这项技术，我们在此 sprint 中添加了创建和识别此类分区的能力。它看起来像这样

一致的存储方案 (SLE-12-SP4 / yast2-storage-old)

我们修复了一个 bug，如果在使用基于分区和基于 LVM 的/加密的 LVM 之间切换存储方案时，行为不一致：bsc#1085169。

这种行为非常令人恼火：最初，它会建议创建一个单独的“/home”分区，但是当你更改方案参数并简单地勾选该复选框 “[x] separate /home” 时，它会抱怨使用当前设置无法创建单独的“/home”。

两种代码路径的计算方式不同：一种考虑了也建议的其他分区，例如“swap”和“boot”（或“PrEP”或“/efi-boot”），另一种则没有。我们尽可能地统一了它们，而不会破坏任何东西，但是由于计算何时以及如何使用任何引导分区在该旧遗留存储堆栈中非常复杂，因此我们没有做到最好；引导分区非常小，因此它们的大小仅在非常病态的边缘情况下才重要。我们尽量不要过度设计，尤其是在针对商业产品的第四个服务包时。

有关更多详细信息，请参阅修复 pull request。

分区程序展望未来

我们已经大量介绍了 Storage-NG 及其将为用户带来的可能性和功能。但是，它的强大功能在表面之下仍然处于休眠状态，因为我们决定克隆经典 YaST 分区程序的 UI 和功能，以满足 SLE 15（和 Leap 15.0）的截止日期。但是现在，我们终于能够开始公开那些期待已久的功能，并为当前的 Tumbleweed 以及未来的 SLE-15-SP1 和 Leap 15.1 带来新的功能。

分区程序的 UI 已经塞满了功能，但我们希望避免过于颠覆性的重新设计。所以是时候进行一些笔和纸的会议了，尝试找到并绘制一种将令人兴奋的新内容添加到分区程序的好方法，包括以下所有内容

允许将整个磁盘（没有分区表）添加为软件 MD RAID 的成员。
管理（创建、修改和删除）软件 MD RAID 设备内的分区。
可以格式化整个磁盘（没有分区表）和/或为其定义挂载点（就像我们对分区或 LVM 逻辑卷所做的那样）。
管理 Bcache，以便用户可以设置和配置哪些设备将用于加速其他设备。

像往常一样，我们在此过程中咨询了一些 UI 专家，结果是这个文档的第一个版本，总结了如何将所有这些内容合并到分区程序中，包括我们正在考虑的近期的替代方案。

该文档将成为未来开发的基础。有时，您需要花费一个 sprint 来做其他事情（例如研究和记录），然后才能继续编写代码。

分区程序：将整个磁盘作为软件 MD RAID 的成员

前一文档中描述的功能已经可供 Tumbleweed 用户使用（或者一旦集成过程完成就会可用），因此，已准备好用于即将发布的 SLE 和 Leap 版本。现在，分区程序在 RAID 屏幕上将整个磁盘（没有分区表）作为“可用设备”提供，遵循文档中解释的标准和注意事项。

这带来了更多将设备组合在一起（磁盘、分区、软件 RAID，您说得对）的方式来创建存储设置。因此，我们认为解释某些组合立即不可行的原因很重要，可能是因为它们需要一些先决步骤。这使我们…

分区程序：更具体的错误，当设备正在使用时

通常，分区程序中已经存在的大多数检查已经能够正确处理磁盘是 MD RAID 或 LVM 卷组的直接成员的情况。但是，设备正在使用的消息不够信息量。

现在，该消息包括使操作不可能的设备的名称（通常是一个，但在某些情况下可能不止一个），因此用户可以了解如何修复它。

分区程序：改进分区表的创建

分区程序的一个特别糟糕的部分是在解释当前情况和可能后果方面，也是“创建新分区表”的工作流程，它还表现出与分区程序其余操作不一致的行为。

在 SLE-15 和 openSUSE Leap 15.0 中，“创建新分区表”按钮会立即显示一个表单，以选择分区表类型（如果设备支持多种类型）。

并且在用户选择一种类型之后，它始终会显示有关所有类型设备将被破坏的警告，无论某些设备是否真的受到影响。

甚至更好的是，如果只可能有一种分区表类型，它仍然会显示表单，但不会提出任何问题。因此，在完全空的 DASD 设备上创建分区表会导致误导性的警告（将不会破坏任何东西）在空向导之上。

因此，整个操作已重新实现，仅当某些设备确实受到影响时才显示警告（包括受影响设备的列表），并且在用户单击按钮时立即显示该警告（就像任何其他分区程序操作一样）。

如截图所示，该检查可以正确处理磁盘作为整体（没有分区）是 MD RAID 或 LVM 设置的一部分的情况。当然，在 DASD 或类似情况下没有空的向导步骤。现在，工作流程在每种情况下都以预期的方式工作。

简而言之，Storage-NG 分区程序正在逐步摆脱对历史分区程序的 1:1 克隆，以提供更多功能和可用性。并且在该领域还有更多改进。

分区程序：提前卸载设备

分区程序允许您广泛配置系统的存储设备。您可以执行许多不同的操作，从更改文件系统的标签到使用 LVM 或 RAID 创建复杂的配置。您执行的每个修改都存储在内存中，因此实际系统在您确认应用更改作为最后一步之前不会被更改。但是，在某些情况下，分区程序可能无法执行某些必需的操作，并且在尝试修改实际系统时会失败。其中一个可能失败的操作是卸载设备。此操作可能因多种原因而失败，但最常见的原因是文件系统正在使用中。而且，有时有一些操作需要设备被卸载，例如删除分区，因此分区程序会尝试自动卸载它。

在此 sprint 期间，分区程序恢复了在应用更改时避免可能失败的动态卸载设备的能力。现在，如果您想删除当前挂载的设备（例如 LVM 逻辑卷），您将被提前要求卸载它。如果您接受，分区程序将尝试在不等待应用所有更改的情况下动态卸载该设备。如果卸载操作失败，您将被告知该问题，并且您可以在分区程序应用更改到您的系统之前尝试手动解决该问题。当然，您也可以在不卸载设备的情况下继续，分区程序将在您接受所有更改后尝试自动卸载它。