Multi-Arch SIG成立于2019年12月，距今已有一年多了，本报告总结了过去一年OpenStack社区中有关Multi-Arch SIG的最新信息。

什么是Multi-Arch SIG？

简而言之，为了使OpenStack可以更好地与不同的CPU架构集成，Multi-ArchSIG包含了相关的所有工作。在上海峰会（2019年11月）期间，当时这个Multi-Arch SIG还只是一个想法，我们进行了很多讨论。讨论从仅支持ARM64开始展开，不久便纳入了支持其他CPU架构的想法，因为我们发现对大多数CPU架构的支持都面临着相同的问题，并且需要修改的代码非常相似（在多数情况下，不同架构需要相同的代码更改集）。从那时起，SIG似乎变成了从一种CPU架构支持到另一种CPU架构支持收集经验的最佳场所。这些经验会被记录下来，并提供给整个OpenStack社区和可能感兴趣的用户。因此，我们成立了Multi-ArchSIG来支持这些目标。请记住，SIG是协作的场所，并且可进行跨关联扩展。

加入Multi-Arch SIG吧！

我们希望帮助社区更好地支持多种架构，同时也需要有更多的帮助，更多的人手和更多的资源来实现该目标。

我们在组建Multi-Arch SIG的第一天就创建相应的SIG Etherpad，并保留着持续更新的信息和相关链接。另外，大家可以查阅2020年线上项目小组集会（PTG）的Multi-ArchSIG会议上的Etherpad。这两个Etherpad可帮您初步了解该SIG的简介及其正在进行的工作。

SIG Etherpad:

https://etherpad.opendev.org/p/Multi-arch

2020 PTG Etherpad:

https://etherpad.opendev.org/p/Multi-arch-2020-VPTG

2020线上PTG截图

我们还将尝试在SIG的StoryBoard上汇总社区实践与成果（无论是否来自于这个SIG）。如果大家有任何疑问、想法或可为OpenStack的多体系架构提供支持，请随时与我们联系。

下面是大家可以联系到我们的一些方式：

IRC:#openstack-multi-arch
会议 (按需): http://eavesdrop.openstack.org/#Multi-Arch_SIG_Meeting
邮件列表: 在OpenStack Discuss邮件列表里使用"[Multi-archSIG]" 或者 "[Multi-arch]" tags <openstack-discuss@lists.openstack.org>
StoryBoard: https://storyboard.openstack.org/#!/project/openstack/multi-arch-sig

我们用这个StoryBoard收集社区里所有关于多体系架构的工作和尝试。同时也收集用户案例以及bugs。
如果通过以上方式都联系不到我们，或者大家遇到任何困难，可随时联系SIGchairs 或是任何一个SIG成员来提供服务/咨询或帮助大家加入SIG。现在的SIGchairs是:Rico(林冠宇) <irc:ricolin><email: rico.lin@easystack.cn or ricolin@ricolky.com>

让我们知道大家对什么感兴趣，或大家为支持OpenStack多体系架构所做的工作。一旦取得更多进展，我们将尝试继续生成报告（期待大家的故事或工作共享），请持续关注吧。:)

如果有些人还不知道multi-arch是什么的话…

什么是multi-arch?

本段内容来自：

https://docs.openstack.org/multi-arch-sig/latest/what-is-multiarch.html

Multi-arch是一个统称，旨在使OpenStack在任意（特定）系统架构上都可运行。事实上，这也受到了许多行业的重点关注。

持续集成与测试（CIand testing）

我们需要在多种架构上测试OpenStack。理想情况下，上游应具备持续集成任何相关系统架构的功能。另外，也可以考虑采用该功能测试新用例。

打包、容器与镜像

软件包和容器应该为所有系统架构构建。请牢记“管理二进制工件（BinaryArtifacts）发布准则”。

部署工具

OpenStack部署工具应支持在非x86架构上进行部署。换句话说，工具应支持非x86架构所需的任何特殊步骤。支持采用混合架构部署云平台的技术也很有价值。请注意，部署工具通常会对其所部署的组件进行预判，因此部署工具中对多种架构的支持可能取决于工件（artifacts）的可用性。

Virt驱动程序

运行OpenStack通常意味着由Nova管理虚拟机。从多架构的角度来看，这意味着要了解Virt驱动程序。更具体地说，LibvirtKVM驱动程序应该可在非x86架构上运行（已实现），并且应该保持FeatureSupport Matrix的准确性。还有一些针对特定架构的虚拟化技术，例如PowerVM和Nova中带有Virt驱动程序的z/VM，这些都是多架构场景的一部分。

布道传播

应明确多架构的价值。

为什么在OpenStack中支持多种架构很重要？

OpenStack的测试对于证明CPU架构的功能来说是一个很好的沙箱，因为OpenStack会触及到Linux系统许多组件的方方面面，它与网络、虚拟化、文件系统、磁盘管理、Python、Web服务器、数据库服务器、amqp服务器等进行交互（这份列表还在持续增加）。如果大家可以在某个CPU架构上运行OpenStack，则很有可能可以运行大多数其他软件。

而且，对于x86我们看到了可行的替代方案，在某些情况下，它们可能会提供更高的每美元性能或每瓦性能。

目前对多架构的支持进展到什么阶段了?

当前，x86 CPU架构仍然是唯一经过OpenStack社区全面测试的架构。但是，已经有案例表明OpenStack可以在实际生产中的多个CPU架构上完全部署。已经有供应商提供带有ARM64节点的OpenStack系统投入生产。Linaro甚至慷慨地向OpenInfra基金会（开源基础设施基金会）捐赠了ARM64 OpenStack环境（感谢Marcin Juszkiewicz，赵帅和实现这一目标的Infra团队）。当前，这是我们社区中唯一的非x86持续集成环境。有关此Linaro环境的更多信息，请查看超级用户专栏“Arm如何成为OpenStack中的头等公民”。

在OpenStack社区的相关工作

ARM64单元测试覆盖

我们目前有一个单元测试Job (由Rico林冠宇实现)用于在ARM64 CPU架构上进行测试。Zuul测试Job模板“openstack-python3-wallaby-jobs-arm64”目前已包含一项Zuul测试Job“openstack-tox-py38-arm64”。单元测试工作会在ARM64架构Python3.8环境里运行。

目前，已有人建议其作为一个单独的Pipeline“check-arm64”上的无表决权测试Job，以便于其他开发小组采用这份测试Job，因为它不会影响到其他项目小组当前的开发以及审查流程，而且还可检查补丁在ARM64环境中如何工作。这项测试Job目前正在某些核心项目（例如Nova，Neutron，Ironic，Keystone等）中运行和测试。一旦所有核心项目（以及可能需要针对多个CPU架构进行测试的其他项目）都采用了这项测试Job，我们就可以提供更好的性能保证，以便在ARM64上运行OpenStack服务。另外，现在可以利用Zuul来检查测试Job的状态/健康状况。

持续检查测试Job状态非常重要，因为我们希望在不同的环境中提供稳定的服务。在工作稳定并通过大多数项目的测试之前，我们没有设定任何时间表将工作转为投票。因此，目前我们设置了两个后续任务：检查并维护此工作，并尝试让更多项目采用此工作，同时确保该工作保持稳定和健康。

面向ARM64的Python wheels支持

OpenStack已开始支持为非x86 CPU架构构建和发布Pythonwheels。自2020年5月以来，支持为ARM64架构构建和发布Pythonwheels的Zuul测试Job已经被添加到OpenStack里来（由Marcin Juszkiewicz和Ian Wienand实现）。

这些测试Job作为定期任务运行，以构建和发布用于OpenStack CI镜像的ARM64wheels。从这一步开始，我们应该能够直接从OpenStack社区获得ARM64特定的Pythonwheel软件包。并且我们上面讨论过的单元测试Job或任何其他ARM64 Python测试Job实际上将会在一个专门为ARM64构建的Python包的ARM64环境中运行。当前，ARM64是唯一具有预构建Pythonwheels的非x86 CPU架构，因为我们仍然需要有人捐赠在特定架构下的运行场景，然后感兴趣的开发人员才可以加入并添加对特定CPU架构的支持。

面向ARM64的场景测试（进行中）

我们仍在尝试在OpenStack社区中添加一项CI Job（由赵帅，Rico林冠宇和Ian Wienand开发），用于为Devstack安装服务并在ARM64环境上运行一整套相关的场景测试Job。

大家可在此处发现一个细节，我们在Nova libvirt config中指定cpu模型，因为aarch64没有默认的cpu模型。

我们仍在努力调整测试Job性能，并试图使其尽可能稳定。一旦有了足够的信心，我们就会将其介绍给其他项目。可以观察到，当前的性能是低于x86CI环境的。通常会分配三到四倍以上的CPU资源。因此，与具有相同性能的x86上的场景测试任务相比，我们确实使用了CPU数量更大的flavour。同样，大多数测试成功完成，没有任何问题，但是我们仍然遇到一些不稳定的问题，例如REST调用的“readtimeout”或RabbitMQ的“missed heartbeats from client”，目前暂未发现特别突出的问题。这项任务目前进展比较慢但仍在进行中，一旦完成了这个Devstack测试Job（准备好意味着性能足够稳定），我们将计划如何继续推进以及目标范围是什么。由于CI资源有限，我们必须确保每次使用都有用。再一次感谢捐赠给OIF的每一个CI资源，谢谢Linaro！

在单一ARM64节点上立即构建OpenStack

大家可以通过多种方式在ARM64环境中安装OpenStack，如果正确配置了OpenStack（并假设大家的硬件支持安装），所有安装都会成功。在这里，我们向大家展示如何通过Devstack进行安装。要运行devstack并在ARM64环境上安装OpenStack，只需下载Devstack，在devstack存储库中写入“local.conf”配置文件，最后运行stack.sh。有关一般配置文件的指导原则，请检查这份文档。

[[local|localrc]]

# This area is the min. requirement for devstack config

ADMIN_PASSWORD=secret

DATABASE_PASSWORD=$ADMIN_PASSWORD

RABBIT_PASSWORD=$ADMIN_PASSWORD

SERVICE_PASSWORD=$ADMIN_PASSWORD

#IPV4_ADDRS_SAFE_TO_USE=172.31.1.0/24

#FLOATING_RANGE=192.168.20.0/25

#HOST_IP=10.3.4.5

IMAGE_URLS=https://github.com/cirros-dev/cirros/releases/download/0.5.1/cirros-0.5.1-aarch64-disk.img

DEFAULT_IMAGE_NAME=cirros-0.5.1-aarch64-disk

DEFAULT_IMAGE_FILE_NAME=cirros-0.5.1-aarch64-disk.img

DEFAULT_INSTANCE_TYPE=m1.tiny

BUILD_TIMEOUT=300

ENABLE_VOLUME_MULTIATTACH=False

GLANCE_USE_IMPORT_WORKFLOW=True

DISABLED_SERVICES+=,s-account,s-container,s-object,s-proxy,c-bak

[[post-config|$NOVA_CONF]]

[libvirt]

cpu_mode=custom

cpu_model={Please put yourCPU model here}

num_pcie_ports=15

大家也可以使用Kolla，Helm和其他工具。

各种各样的ppc64le工作

尽管许多社区工作都围绕aarch64，但ppc64le也有一些社区工作。Nova拥有PowerKVM第三方CI已经很长时间了，但是所做的工作远远不止于此。特别是在TripleO和RDO中需要付出很多努力。TripleO对在ppc64le上进行部署提供了良好的支持，尤其是对于将x86_64和ppc64le混合使用的云平台而言。对于社区而言，使用TripleO进行的部署将使用RDO中的内容，并且已经进行了很多努力来使所有RDO内容在ppc64le上正常工作。为ppc64le发布RDO镜像（容器镜像和磁盘镜像）仍然是一个持续的挑战，但是对于社区来说应该很快就会到位。如果大家想帮助发布内容或希望在本地进行构建，请与我们联系。当然，CentOS8中有一些软件包可以在ppc64le（以及aarch64）上部署OpenStack云（基于TripleO或其他）。

跨社区工作

OpenStack和Kubernetes

我们还通过添加脚本（由Rico林冠宇创建）来构建和发布具有多种架构的容器镜像，从而促进了kubernetes/cloud-provider-openstack（在Kubernetes社区中）的多架构工作。

我们尝试确保对CPU架构的支持确实适用于用户及其用例。由于Kubernetes是OpenStack上最受欢迎的用例之一，因此我们也向Kubernetes社区迈进一步，并尝试确保多架构方案适用于OpenStack上的Kubernetes。我们要做的第一件事是在OpenStack云供应商中添加对多架构的支持。

Kubernetes的云服务供应商是什么？

这是一种插件机制，允许不同的云供应商（OpenStack，AWS，GCE等）将其平台与Kubernetes集成，因此管理员可以通过cloud-controller-manager组件管理这些资源，以实现特定于云的控制逻辑。

这种机制使OpenStack可以更紧密地集成到Kubernetes项目中。并且为OpenStack云供应商引入对多种架构的支持，使所有社区成员都可以直接从社区获得认证的镜像。它目前还不是由社区自动构建和发布的，但是我们计划将来由CI测试Job自动构建和发布那些多架构的容器镜像。

还有一个开发人员文档，向大家展示如何为多种系统架构构建OpenStack云供应商的容器镜像，因此在完成社区中的自动化工作之前，大家也可以遵循这份文档并使用Makefile脚本来构建和发布自己的镜像。只需运行：

exportARCHS='arm64'
makeupload-images

这将帮助大家构建所有用于arm64体系结构的OpenStack云供应商镜像并将其发布到大家的容器镜像存储库中。这个命令将构建Go软件包，并在基本镜像之上添加一些必需的依赖项（大多数使用alpine：3.11，只有cinder-csi-plugin使用debian-base：1.0.0）。它将构建大家要求的所有体系结构所需的所有镜像。最后，大家可以通过dockerpush推送镜像（当然，大家可以将docker覆盖到各自想要的任何其他容器引擎上）。

OpenStack和OpenEuler

OpenEuler是最新的开源操作系统，在国内颇为著名并得到广泛使用。它诞生于华为，随后迅速吸引了众多公司和贡献者，使其成为开源OS社区中的一等公民。它基于rpm，并支持x86和aarch64架构。OpenStack和OpenEuler之间的集成主要包括两个部分：

在上游层面，OpenDev CI要支持openEuler。这部分意味着在devstack中支持openEuler并通过测试。另外，diskimage-builder也要支持openEuler。Linaro为此做出了一些努力，我们已经完成了POC，并将补丁提交给了devstack以支持这个功能。用于构建OpenEuler的diskimage-builder支持正在进行中。
在发布层面，OpenEuler建立了一个OpenStack SIG，负责发布OpenStack软件包。已经为OpenStack软件包修复了很多依赖关系，并且SIG正在努力为OpenEuler21.03支持OpenStack V版本。

跨项目工作

我们已经做了很多工作为整个OpenStack社区提供了对多构架的支持。

Kolla支持测试Job（感谢Marcin Juszkiewicz）来构建和发布aarch64的容器镜像。Kolla中还有代码可确保成功构建ppc64le和s390x的容器镜像。TripleO以前使用过这些ppc64le容器。
Nova，Neutron项目下面的多个补丁程序可支持不同的CPU架构。与Novalibvirt驱动程序一样，对于非x86架构也有一些修复，因为驱动程序本身已在社区的x86架构上进行了全面测试。因此会发生诸如“Fix checkamd_sev_support on AArch64 [fixed]”之类的问题。这里还提到了一些以前的修复程序。
Magnum为Fedora Atomic驱动支持Arm64。
面向diskimage-builder的Arm64功能测试。
社区基础设施中的新Pipeline“check-arm64”（感谢IanWienand）将ARM64 CI工作流程与x86分开。
如果大家在整个社区中进行探索（例如搜索“ aarch64”或“ppc64le”），会发现更多为多架构而战的OpenStacker们。

文档

我们记录了一些基本方面（感谢Jeremy Freudberg），以使大家获得一些基本清晰的信息-一旦我们取得了更大的进步或人们愿意对其进行更新，就需要对其进行改进。还有其他一些文档，例如Nova的矩阵支持，以解释在不同架构下的功能。这个矩阵可能不是一直都是最新的（因为某些CPU架构的缺失功能可能在我们更新此矩阵之前就已实现），但它仍然具有一定的参考价值。

OpenStack缺少什么

这里我们收集了一些缺少的资源/功能以及其他非x86架构要注意的事项

CI 资源：社区支持特定的CPU架构并能够构建、测试和发布服务的前提就是拥有CI资源。目前，我们只有一个来自Linaro的用于ARM64环境的集群。这是ARM64的良好开端，但也意味着其余的非x86架构将无法获得社区的太多保证（这并不意味着它的价值或可用性不高，只是社区没有太多做得更好的支持）。第三方CI也可以，但是完整的社区基础设施会更好。
支持异构部署的部署工具：许多部署OpenStack工具仅通过指向不同的内容就可以部署非x86系统架构，但是很少（可以肯定的是，像上面讨论过的TripleO）可以对多种架构进行部署。由于成本或兴趣不同，拥有一个具有多种架构的单个云计算平台很有用。
进行全面测试的多架构：ARM64是我们可以获得的经过测试最严格的非x86架构，但是仍然缺少用于进行情境测试的功能测试Job（仍在进行中），并且仍然需要将单元测试Job付诸表决。

峰会议题

在过去的峰会上有很多与多架构相关的议题。而且，Multi-ArchSIG将继续努力，将来提供更多有关多架构支持的技术分享。

大家可以在线找到大多数演讲视频（例如与Arm64相关的视频）

一些为新手推荐的议题：

OpenStack的多架构支持

-来自Multi-Arch SIG的2020报告
基于Arm体系结构的云计算的进展

-对使用ARM体系结构的当前云的分析

-提供了来自Linaro的工作分享

-提供了来自EasyStack和华为关于ARM64支持的一些商业视角

-在这个议题里，超级用户有一篇很棒的文章，由赵帅，郑振宇和郭长波撰写，精彩不容错过！
三个ARM化的OpenStack-在ARM上构建和测试OpenStack

-提供一些关于构建与测试的经验之谈
基于ARM的Kata Containers，让我们谈谈进展!

-提供了基于ARM的Kata更新

还有其他精彩的议题我们这里没有列出，例如演示或市场分析议题，所以请继续寻找适合各自的议题。

OpenStack Multi-Arch SIG年度报告