Charmstore 到 Charmhub 迁移¶
本文档提出了一种新的、更好但替代的维护和发布 OpenStack charms 的方法，适用于拥有新的 charm store (charmhub.io) 的世界，该 store 提供了更丰富的 charm 交付机制。
引入了一个新的 charm store，charmhub，它与 snaps 共享特性和功能。旧的 charm store，jaas.ai，计划退役，所有交付 charms 的项目都应迁移到 charmhub。charmhub 的一个引人注目的特性是能够为发布提供多个 track。
这些 charms 本身被编写为支持多个 OpenStack 版本，从 pre-Mitaka 到 Xena。这对于 charm 的开发人员来说，一次只在一个分支上工作来说很方便，但要求代码和依赖项向最低共同支持的基线工作。这存在问题，因为这些 charms 依赖于正在前进并停止对旧 python 版本（如 Python 2、3.5 及更高版本）的支持的 python 库，这给当前的 charms 维护带来了挑战。
问题描述¶
目前，OpenStack Charms 在两个 charmstore 命名空间中交付 - openstack-charmers 和 openstack-charmers-next。使用两个命名空间早于 jaas.ai charm store 中的 channels 的存在。这些命名空间分别等同于 stable 和 edge channels。
托管 OpenStack charms 源代码的 git 仓库通常位于 opendev.org git 服务器上。这些仓库包含每个稳定 charm 版本的分支以及一个不稳定的开发分支 (master)。CI 系统中的 post-merge 任务在任何更改合并后将更新的 charm 版本发布到 jaas.ai charm store。合并到 master 开发分支的更改发布到 openstack-charmers-next 命名空间，合并到最新稳定分支的更改发布到 openstack-charmers 命名空间。
当前方法的一个挑战是，这两个分支必须关注依赖项的最低共同基线；这意味着用于 charms 的大多数 python 库必须限制为支持仍然包含在较旧 OpenStack 版本中的旧 python 版本。随着 python 库开发世界的进步，对旧 python 版本的支持正在被弃用和删除，这给当前的 charms 带来了各种维护难题。
这种方法的另一个挑战是，每个引入的新功能都会给较旧的安装库带来潜在的风险。为了缓解这种情况，OpenStack Charms 的 gate 测试会在大量的 OpenStack 和基础 distro 版本上运行广泛的测试采样。新的贡献者经常遇到 CI 系统的问题，并且需要调试旧版本，即使他们的补丁与这些旧版本无关。
这种安排的一个积极方面是，开发人员主要只需要考虑两个分支 - master 开发分支和最新的稳定分支。所有补丁主要针对 master 开发分支，相关的 bug 修复会回移植到单个版本。
提议的变更¶
OpenStack charms 将采用一种发布和交付模型，该模型利用了 charmhub 提供的各种交付渠道，与 Snap store 中的 channels 密切匹配。请注意，并非所有 charms 都将支持特定服务的所有发布/版本，并且 charms 仅会采用与该服务本身相关的发布和 track。
Tracks¶
Tracks 将设置为跟踪上游仓库中的 git 分支，并将导致每个 charm payload 版本的 track（例如，它交付的软件服务）。当 charm 的主要软件 payload 使用众所周知的发布名称时，track 名称将使用发布名称而不是版本号。当 charm 的主要软件 payload 不使用众所周知的发布名称时，将使用软件的版本。
例如，nova-compute charm 交付 nova hypervisor 服务，该 charm 的 track 将对应于安装的 nova 服务的 OpenStack 发布版本（例如，ussuri、victoria 等）。
另一个例子是，OVN Central charm 交付 OVN 作为 payload，OVN 使用 YY.MM 的发布名称/版本。在这种情况下，OVN charm Central charm 将提供一个对应于 YY.MM 命名方案的 track（例如，21.03、21.09 等）。
风险等级¶
charmhub store 还允许开发人员和用户提供和使用不同的风险等级。此功能也可用在旧的 charmstore 中，但是直到最近才被发布过程利用。任何 track 中都有 4 个风险等级：edge、beta、candidate 和 stable。CI 系统将自动为任何合并到相应 git 分支的更改发布一个新的 charm 到 edge 风险等级。
charms 将由人工行为员通过 edge -> beta -> candidate -> stable 风险等级进行提升，而不是通过自动化脚本。可以开发工具来协助此过程，但自动提升目前不在范围内。未来的增强功能可能包括在引入 git 标签时触发构建的提升，但这被认为不在此工作范围内。
分支¶
charmhub store 还提供对 track 和风险等级的进一步细分，即分支，旨在为 bug 修复目的提供临时、短期的发布。关于如何将分支流程融入 OpenStack charms 的开发流程，有各种可能性需要考虑。
就本次工作而言，分支明确超出范围，应单独考虑。
Git 分支¶
需要在 Charmhub 中交付的各种 track 中创建 git 分支。git 分支和 charmhub track 之间的关系是多对一，这意味着合并到单个分支的更改可能会导致 charm 发布到多个 track。当 track 提供逻辑上不同的目标时，这很有用，而分支提供相同的功能。例如，最新的 master 分支开发逻辑上指向最新的 OpenStack 发布版本以及最新的/edge 发布版本。
此外，每个 git 分支和 track 中的 charms 旨在支持目标发布 N 和之前的发布 N-1 以进行升级目的。
OpenStack Charms¶
对于专门交付 OpenStack 服务的 charms，将为该 charm 支持的每个 OpenStack 版本创建一个新的 git 分支。该分支将以 stable/<openstack-release> 的形式命名，适用于所有稳定的 OpenStack 版本。分支将仅创建到 OpenStack 的 Queens 发布版本。这些分支将以当前稳定 charms 发布的顶端 (stable/21.10) 作为基础创建。这些分支将彼此不同，具体取决于它们所针对的主要软件版本以及它们所部署 track 的默认配置值。
Git 分支 |
Charmhub Track(s) |
|---|---|
stable/queens stable/rocky stable/stein stable/train |
train |
stable/ussuri |
ussuri |
stable/victoria |
victoria |
stable/wallaby |
wallaby |
stable/xena |
xena |
stable/yoga |
yoga |
master |
zed, latest/edge |
Ceph Charms¶
目前，Ceph 更新通过 Ubuntu Cloud Archive 交付，这使 ceph charms 与 OpenStack 版本相关联，从而在定义每个 Ceph 版本的 track 时带来一些挑战。在服务共存的情况下（例如，nova-compute 和 ceph-osd），更新 ceph-osd charm 的源代码会对 nova-compute 服务及其版本产生意想不到的后果。与其引入复杂的 pinning 或新的软件包存档，用于交付 Ceph 的 charms 将跟踪 OpenStack 发布名称以及 Ceph 发布名称，直到 Octopus 发布为止。预计这将使用户的迁移更容易。
开发 git 分支将根据交付产品的适当 Ceph 版本创建。为了方便用户迁移，Ceph charms 可能会将单个分支交付到多个 Charmhub track。
Git 分支 |
Charmhub Track(s) |
|---|---|
stable/luminous |
luminous, queens, rocky |
stable/mimic |
mimic, stein |
stable/nautilus |
nautilus, train |
stable/octopus |
octopus |
stable/pacific |
pacific |
master |
quincy, latest/edge |
在较新的分支上，可以安全地将 Ceph 发布名称转换为 cloud-archive pocket，假设 OpenStack 和 Ceph 版本之间的有效映射已明确记录。
Ceph 发布版本 |
OpenStack 发布版本 |
|---|---|
Luminous |
Queens |
Mimic |
Stein |
Nautilus |
Train |
Octopus |
Ussuri |
Pacific |
Wallaby (中期 Openstack，更多支持) |
不稳定 / Quincy |
瑜伽 |
上述工作可行，因为我们可以安全地将 distro (bionic-queens) 与 Rocky 结合使用，并且我们可以安全地将 Pacific 的 focal-wallaby 与 Xena 结合使用，因为 Xena 包具有更高的版本。
Ceph charms 包括以下 charms
ceph-fs
ceph-iscsi
ceph-mon
ceph-osd
ceph-proxy
ceph-radosgw
ceph-rbd-mirror
ceph-dashboard
特定于提供商的附属 charms¶
一些服务，例如 Cinder 和 Neutron，允许使用特定于提供商的附属 charms，以便允许特定的 SDN、存储插件等。这些特定于提供商的附属 charms 被认为是支持 charms 而不是 OpenStack 特定的 charms，但是它们通常会为特定的存储后端启用特定功能。因此，它们将遵循 OpenStack Charms track 模式。
这些 charms 将包括以下附属 charms，截至撰写本文时包括
cinder-ceph
cinder-lvm
cinder-netapp
cinder-purestorage
neutron-openvswitch
neutron-api-plugin-arista
neutron-api-plugin-ovn
keystone-saml-mellon
OVN Charms¶
OVN 是一种网络 SDN，用作 Charmed OpenStack 部署的主要 SDN。OVN 已通过 Ubuntu Cloud Archive 以及 Ubuntu 存档提供。OVN charms 在提供源版本方面有些混合。例如 OVN Dedicated Chassis 和 OVN Central 等独立 charms 具有允许配置用于软件包安装的存档的选项。作为附属 charm，OVN Chassis 将采用与主 charm 一起安装的版本。
由于 OVN 是一种通用的 SDN，而不是专门为 OpenStack 实现的，因此 charmhub 中的 track 应密切遵循交付的软件版本，而不是 OpenStack 发布版本。这最初可能会让用户迁移感到困惑，但应通过清晰的文档以及帮助最终用户选择适当的 track 进行升级的工具来解决。
OVN charms 将具有以下分支和 track
分支 |
Track(s) |
|---|---|
stable/20.03 |
20.03, ussuri, victoria |
stable/20.12 |
20.12, wallaby |
stable/21.09 |
21.09, xena |
stable/22.03 |
22.03 |
master |
latest/edge |
支持的 Charms¶
在 OpenStack 生态系统中，还有其他核心服务是生成 OpenStack 云所必需的。这些服务包括消息传递、数据库和证书管理服务。虽然它们对 OpenStack 云的功能至关重要，但它们与特定的 OpenStack 发布版本没有关联，这些 charms 应该会产生适合其特定行为的 track。
这些 charms 由以下服务组成，并将产生基于提供的软件版本的 track。这些服务通常从 Ubuntu 存档（而不是 Ubuntu Cloud Archive）交付，并将跟踪其在 Ubuntu 中的版本。
Charm |
分支 |
Track(s) |
|---|---|---|
hacluster |
stable/bionic |
1.1.x |
hacluster |
stable/focal |
2.0.3, latest/stable |
hacluster |
master |
2.0.5, latest/edge |
pacemaker-remote |
stable/bionic |
1.1.x |
pacemaker-remote |
stable/focal |
2.0.3, latest/stable |
pacemaker-remote |
master |
2.0.5, latest/edge |
rabbitmq-server |
stable/bionic |
3.6 |
rabbitmq-server |
stable/focal |
3.8, latest/stable |
rabbitmq-server |
master |
3.9, latest/edge |
vault |
stable/1.5 |
1.5 |
vault |
stable/1.6 |
1.6 |
vault |
stable/1.7 |
1.7 |
vault |
master |
latest/edge |
percona-cluster |
stable/bionic |
5.7, latest/stable |
percona-cluster |
master |
latest/edge |
mysql-innodb-cluster |
stable/jammy |
8.0, latest/stable |
mysql-innodb-cluster |
master |
latest/edge |
Trilio Charms¶
Trilio Charms 也需要迁移到 charmhub 交付机制。虽然它已实现用于 OpenStack，但 Trilio 软件的版本与 OpenStack 发布版本分开，应使用 Trilio 特定的 track。
trilio-data-mover |
stable/4.0 |
4.0 |
|---|---|---|
trilio-data-mover |
stable/4.1 |
4.1, latest/stable |
trilio-data-mover |
master |
4.2 (?), latest/edge |
trilio-dm-api |
stable/4.0 |
4.0 |
trilio-dm-api |
stable/4.1 |
4.1, latest/stable |
trilio-dm-api |
master |
4.2 (?), latest/edge |
trilio-horizon-plugin |
stable/4.0 |
4.0 |
trilio-horizon-plugin |
stable/4.1 |
4.1, latest/stable |
trilio-horizon-plugin |
master |
4.2 (?), latest/edge |
trilio-wlm |
stable/4.0 |
4.0 |
trilio-wlm |
stable/4.1 |
4.1, latest/stable |
trilio-wlm |
master |
4.2 (?), latest/edge |
安装源¶
OpenStack charm 集合中的大多数 charms 提供了一个配置选项，允许用户设置安装 debian 包/snaps 的存档或存储库。这通常通过 openstack-origin 或 source charm 配置选项提供，默认情况下使用本地安装的默认分发存储库。
为了确保 track 正在安装适当版本的软件包，此配置选项的默认值将设置为 track 的适当安装源。如果 track 跨越多个 distro 发布版本（例如，LTS 发布版本交叉处的 cloud-archive），则 charm 需要能够确定是应该从 cloud-archive 还是分发版获取，具体取决于哪个版本是适当的。
主要，这将影响使用 Ussuri Ubuntu Cloud Archive 和 Yoga Ubuntu Cloud Archive 作为安装源的 track。
Latest Track¶
charmhub 中的“latest”track 是它自己的 track，与其他 track 一样 - charms 可以推送到 track 以及 track 内的各种风险等级。虽然它是一个完整的 track，但对于最终用户而言，它是一种获取软件“最新”版本的方式。但是，必须考虑风险等级才能确定应安装哪个版本。
latest track 将以两种方式使用
最新的/稳定 (`latest/stable`) 轨道将被用于停靠稳定的 21.10 charms 发布，直到（至少）22.10 发布。
在 22.10 时，`latest/stable` 轨道将跟随当前的稳定发布，对于 22.10 这将是 `zed` 轨道。
原因是 21.10 charms 的元数据声明了对 focal 的支持，针对 `all` 架构，因此在发布 jammy 及更高版本的 charm 到该频道之前很难替换。然而，zed charms 将仅支持 jammy 和 kinetic，因此它们可以与现有的 21.10 charms 一起发布。然后现有的 21.10 charms 不会升级，因为新的 charms 不支持 focal。因此，在这一点上可以安全地重新使用 `latest/stable` 轨道。
风险¶
每个轨道中每个风险等级的目的是如下所示
Edge¶
对于每个 charm，latest/edge 频道将始终映射到当前 master 开发分支。
目前，对于稳定分支，edge 轨道将不被使用，因为 Launchpad 构建器将直接推送到稳定轨道。这符合现有策略，即需要对稳定分支进行 2 x +2 次 gerrit 审查。在未来的某个时间点，将引入自动化/策略来首先推送到 edge，然后进行测试/策略以推广到更稳定的风险。
Beta¶
beta 风险等级将在 charm 开发周期内的里程碑发布期间使用。
Candidate¶
`
Stable¶
稳定轨道将跟踪稳定、经过测试、发布的 charm 版本。
Technology Preview Charms¶
Charms 最初以“Technology Preview”（技术预览）状态发布。处于技术预览状态的 charms 在确定其对应 payload 发布稳定之前，不应被提升到稳定频道。一旦它毕业，所有被评定为从技术预览毕业的发布都将被提升到稳定频道。并非 charm 的所有轨道都可能具有稳定的风险等级。仍然处于技术预览状态的 charms 将仅将这些 charms 提升到 beta 频道，直到确定 charm 已达到成熟度，此时可以根据需要将其提升到 candidate 和/或稳定频道。
例如，像 ovn-chassis 这样的 charm 可能会以 Stein 发布轨道的形式提供技术预览，但可能直到 Train 发布轨道才达到成熟度。该 charm 的 Train 发布轨道将被提升到稳定频道，但 Stein 发布轨道仅在 beta 频道中具有该 charm。
对于在本次过渡时被认为是 Technology Preview 的 charms，需要特别考虑。Technology Preview charms 不会在 charm store 中发布，并且在 `openstack-charmers` 命名空间下可用。Charmhub 没有以相同方式的命名空间，这些 charms 存在但以 ‘openstack-charmers’ 名称为前缀，例如 openstack-charmers-ironic-api。这些 charms 将在 charmhub 中创建并提升到 beta 频道。
持续集成¶
Charmhub 将交付为特定架构构建的 charms。到目前为止，OpenStack charms 使用 python 模块在 amd64 架构上构建并分发。通常可以接受，因为它们主要是具有交付项的源 charms，但对于具有本机扩展的非 amd64 架构可能会带来一些有趣的挑战。
OpenStack CI 系统当前由 Zuul-CI 系统组成，该系统用于触发每个提议到 charm 的 pep8 (pycodestyle)、单元和功能测试。合并后挂钩已注册，会触发 Jenkins 任务以将 charm 发布到旧版 charm store。
发布 Charms¶
对于通过 charmhub 交付的新型 charms，预计它们将具有特定于平台的 charms，以便可以为适当的目标架构构建 charm 所需的本机扩展或工具。Launchpad 现在提供 charm recipes，可用于以类似于 snap recipes 的方式构建和发布 charms。合并到存储库中的更改将触发在所有受支持的架构上构建 charm，并将结果 charm 发布到 Charmhub。利用此服务消除了 OpenStack Charmers 维护的 CI 系统从 charm store 发布 charms的一个步骤，并完全消除了 CI 基础设施中对 jenkins 的需求。
Launchpad charm recipes 要求知道 git 树并存储在 Launchpad 本身中。为了继续使用上游 OpenStack gerrit 审查系统，这是 OpenStack 服务的标准，并且多年来一直是 charms 的标准，Launchpad 中的每个 charm 项目都将配置为从上游 opendev git 系统镜像源。
将为每个 charm 的每个分支创建一个 charm recipe，以便在上游 gerrit 存储库中合并补丁时，Launchpad 服务将更新镜像（也称为导入）的存储库，检测到存在新更改，启动 charm 构建并将这些结果发布到 charmhub 中的适当频道。
请注意，Launchpad 中的 charm recipes 默认情况下仅每小时构建一次。虽然通常在将 charms 发布到 charm store 时会有轻微的延迟，但每次更改 charm 都会发布一次。在 Launchpad 构建模型中，可以排队多个更改并包含在一个构建中，除非在每小时时间窗口内明确请求构建。这被认为是 charm 开发和发布的可接受的。
测试 Charms¶
随着每个 OpenStack 发布分支和轨道的引入，不再需要针对每个更改测试多个 OpenStack 发布。相反，将运行针对分支的测试。例如，针对 stable/xena 分支的 Keystone charm 的更改将仅运行与 OpenStack Xena 发布相关的测试。
减少在 gate 中运行的发布版本允许 charm 专注于特定的 payload 发布，而不必担心旧版本上的虚假故障。
分支也可能包括测试 N-1 版本的发布软件，以便验证从 N-1 升级到 N 是否正常工作。
Charmcraft¶
为了利用 Launchpad 中的 charm recipes，所有 charms 都需要使用 charmcraft 工具构建。然而，charmcraft 旨在构建和发布 operator framework charms，这排除了 OpenStack charms 集合中的大多数 charms。
Charmcraft 最近与 snapcraft 工具集实现了平价，允许使用各种插件代替默认 charm 插件。‘dump’ 插件适用于经典 charms，但不适用于 reactive charms。从长远来看，应该为使用 charmcraft 构建 reactive charms 创建一个新插件。从短期来看，可以使用 ‘override-build’、‘override-stage’ 和 ‘override-prime’ 步骤覆盖生成 charm 的各种步骤，这将使用现有的 tox 基础设施来构建、准备和启动 reactive charm。
文档¶
OpenStack Charms 和 Ceph Charms 的文档通常以解决方案级别提供，charm README 文件作为 Charm store 和发布的 OpenStack Charm Guide、OpenStack Charms Deployment Guide 和 Ubuntu Ceph Documentation 中的主要文档来源，提供解决方案级别的文档。
发布说明需要清楚地说明使用和利用 Charmhub 的更改，以及引用迁移文档。迁移文档需要清晰地概述，以便用户可以轻松地从使用 Charm Store 迁移到 Charmhub。
还应在 OpenStack Charm Guide 中提供开发人员文档，以提供有关希望贡献新功能、错误修复等开发人员的详细信息。
备选方案¶
没有真正的替代方案。当 charmstore 到 charmhub 的切换实施时，现有的 `charm` 命令将停止工作，这意味着 Jenkins 中的整个构建和发布系统也将停止工作。因此，唯一的真正替代方案是使用 charmcraft 重新设计 Jenkins 软件，然后使用它来推送到 charm store。
这意味着继续维护 Jenkins，而不是利用 Launchpad 构建器来构建感知架构的 charms。
实现¶
负责人¶
- 主要负责人
Alex Kavanagh
Gerrit Topic¶
N/A
工作项¶
为经典和 reactive charms 生成 ‘charmcraft’ recipes¶
当 git 存储库中的分支发生更改时，Launchpad 可以用于构建 charms。这些构建由 recipes 控制。这项工作的一部分是确保这些 recipes 适用于所有 charms。它们将由中心控制，并在开发周期中作为 charms 的一部分“同步”。
编写经典 recipe
使用 charm-tools `build` 命令编写 reactive charm recipe。
将 recipes 添加到 `release-tools` 存储库。
生成用于管理 launchpad 项目/recipes 的辅助工具/库¶
为了管理 charms、recipes 以及 git 存储库分支与 charmhub 轨道/频道之间的映射，将生成一套工具和配置来管理 charms、分支和轨道数量的复杂性。
基本功能将是
显示配置与 git 存储库和 launchpad recipes 中的实际之间的差距。
显示所需的轨道与 charms 的实际轨道（在 charmhub 中），以生成“请求”以创建新轨道，或删除轨道。
根据配置更新现有的 recipes。
根据需要创建新的 recipes。
仓库¶
最初，现有的 `release-tools` 存储库将是这些工具的收集点，但它已经变成了一个有点混乱的工具转储场，需要进行重大重组。从长远来看，这些工具可能会被分解到它们自己的存储库中，其中配置的更改会自动更新 recipes。
此外，为了管理 recipes，将创建一个单独的 `charmhub-lp-tools` 工具来自动化 recipe 创建、更新、删除和更改，并授权上传到 charmhub。
https://github.com/openstack-charmers/release-tools
https://github.com/openstack-charmers/charmhub-lp-tools
文档¶
工具、配置模式以及系统工作方式的文档将以 Markdown 文件形式存储在存储库中。这样可以确保文档“与代码一起”存在。在可能的情况下，schemas（配置文件）的文档将位于配置文件本身中。
安全性¶
没有额外的安全问题。
运行该工具的用户必须在 `openstack-charmers` 团队中拥有 launchpad 帐户，并在 `openstack-charmers` 团队中拥有 charmhub 帐户。
测试¶
破坏 charmstore 和 charmhub 的可能性很高，因此工具和流程将逐步针对“测试” charms 和低优先级的“真实” charms 进行开发。
阶段 1¶
最初，现有的 charms 的副本将注册到 charmhub（使用新名称），以测试 recipes 和构建 charms 的能力。这是为了验证 charm 构建 recipes 是否适用于经典和 reactive charms。
阶段 2¶
选择两个 charms（名义上，`neutron-dynamic-routing` 和 `manila-generic`），断开与 charmstore 的链接，并确保可以创建轨道、分支和 recipes，以便对 charms git 存储库的更新会导致在正确的轨道中构建 charms。
这将允许将正确的更改枚举到 charms 并捕获到 release-tools 存储库中。
依赖项¶
无
