TripleO Repos 单一来源¶
本提案阐述了使用 tripleo-repos 作为单一来源来安装和配置 TripleO 的非基础 OS 仓库的计划——包括设置所需的 DLRN 哈希值。
https://blueprints.launchpad.net/tripleo/+spec/tripleo-repos-single-source
问题描述¶
在审查代码库时，发现有多个地方指定了仓库。例如，在发布文件中，我们设置了 repo setup role 应用的配置。其他一些仓库/版本配置包含在
rdo 配置（示例）
设置仓库版本的过程需要获取和转换 DLRN 哈希值，例如将“current-tripleo”解析为特定的 DLRN 构建 ID 并指定正确的代理。目前，这项工作的大部分是在发布文件中完成的，导致了许多发布文件中重复出现复杂且脆弱的 Bash 脚本。
这种重复，加上用于设置仓库配置、模块和支持版本的各种位置，令人困惑且容易出错。
应该有一个事实来源来确定 TripleO 部署中安装了哪些仓库以及如何安装它们。将所有这些功能进行单一来源化将避免当前重复、覆盖设置和版本混淆的问题。
提议的变更¶
概述¶
本提案提出使用 tripleo-repos 作为设置仓库配置、模块和支持版本的“事实来源”——包括设置上游开发/CI 工作流程所需的 DLRN 哈希值以指定要安装的确切仓库版本。
拥有仓库配置、模块等的单一事实来源将使开发和测试更加一致、可靠且易于调试。
我们的意图是使用现有的 tripleo-repos 仓库来进行这项工作，而不是创建一个新的仓库。目前尚不确定我们将添加 v2/版本化 API 还是如何处理与现有功能的集成。
我们旨在模块化提议的 tripleo-repos 工作的设计和实现。特别是，已经确定了两个可以独立于 tripleo-repos 实现并最终被 tripleo-repos 消耗的子系统；从已知标签解析 delorean 构建哈希值（即，将“current-tripleo”解析为特定的 DLRN 构建 ID）以及配置 dnf 仓库和模块将作为独立的 python 模块实现，并具有自己的单元测试、cli、ansible 模块等。
集成点¶
tripleo-repos 中的新工作必须支持当前所有使用案例，并且必须与
DLRN 仓库
发布文件
容器和 overcloud 镜像构建
rdo 配置
yum/dnf 仓库和模块
Ansible（Ansible 模块）
推广流水线 - 确保正确的 DLRN 哈希值
合并 DLRN 哈希功能会使工具更加复杂。需要单元测试来防止频繁的破坏。这就是我们决定将此 DLRN 哈希解析拆分为其自己的专用 python 模块“tripleo-get-hash”的原因，以便我们可以对其进行独立的单元测试。
新的 tripleo-repos 工具的范围将限制在上游开发/CI 工作流程中。
替代方案¶
设置仓库、模块和版本的功能已经可用。可以保持现状，或者
使用 rdo 配置设置每个发布版本 - 但是，这不能解决 DLRN 哈希值更改的问题
创建一个 rpm，在其中将 /etc/tripleo-release 放在其中，类似于 /etc/os-release 中的容器工具元数据
安全影响¶
预计不会产生安全影响。这项工作目前在 tripleo 开源仓库中，并将继续在那里进行——只是在一个统一的位置和格式中。
升级影响¶
目前不会产生升级影响。新的 CLI 将支持所有受支持和正在使用的发布版本。在旧 CLI 被弃用后，可能会有一些更新影响。
但是，可能需要对 emit_releases_file https://opendev.org/openstack/tripleo-ci/src/branch/master/scripts/emit_releases_file/emit_releases_file.py 功能与新的 CLI 兼容。
其他最终用户影响¶
新项目分支上完成的工作将提供不同版本的 CLI，v2。在旧 CLI 被弃用之前，最终用户可以选择使用哪个版本的 CLI。
性能影响¶
预计不会产生性能影响。可能通过确保正确且一致地处理代理（发布文件、镜像、rdoproject）来提高性能。
其他部署者影响¶
开发人员影响¶
请参阅 `其他 用户 影响` 部分。
实现¶
添加到 tripleo-repos 的功能将作为 Python 模块编写，并具有 CLI，并且能够执行以下主要功能
单一来源安装所有 TripleO 相关仓库
包括 repo-setup role 中当前可用的功能，包括从模板和文件创建仓库
执行代理处理，例如在发布文件中完成的（镜像、使用 rdoproject 获取 DLRN 仓库）
获取和转换人类可读的 DLRN 哈希值 - 将作为独立的模块实现。
支持设置 yum 模块，例如 container-tools - 将作为独立的模块实现。
支持启用和禁用仓库以及设置其优先级
repo-setup role 将保留，但它将调用 tripleo-repos。所有需要传递给 tripleo-repos 的选项都应在发布文件中。
新项目分支上完成的工作将提供不同版本的 CLI，v2。将在此分支上添加单元测试以直接测试新的 CLI。在 TripleO 团队批准后，CI 将切换到在新分支中运行。所有当前单元测试都应通过新代码。
将添加一个 Ansible 模块，以便直接从 Ansible 调用 tripleo-repos 选项，而无需在 Ansible 中调用 Python CLI。
我们的目标是让 tripleo-repos 成为所有仓库相关配置的单一来源。特别是，我们的目标是服务以下 3 种角色
上游/OpenStack CI 作业
下游/OSP/RHEL 作业
客户安装
为每个使用案例所需的配置略有不同。在上游 CI 作业中，我们需要配置最新的 current-tripleo 推广内容仓库。在下游/OSP 作业中，我们需要使用 rhos-release，在客户安装中，我们需要使用 subscription manager。
由于这些不同的要求，我们倾向于将每个配置存储在其预期位置，上游配置作为“基础”，下游配置在其之上构建（这意味着将使用某种形式的继承来避免重复）。这在 Xena PTG 会议 上讨论过
负责人¶
sshnaidm (DF 和 CI)
marios (CI 和 W-release PTL)
weshay
chandankumar
ysandeep
arxcruz
rlandy
其他 DF 成员 (cloudnull)
工作项¶
建议的时间表¶
调查工作将在 W-release 周期中在 tripleo-repos 的项目分支上开始。该规范将在 X-release 周期中提交以供批准，并且在规范获得批准后，有影响力和集成工作将可见。
依赖项¶
这项工作依赖于 DLRN API 和 yum/dnf。
测试¶
将添加特定的单元测试，并使用基于 python 的代码构建。所有当前的 CI 测试都将通过这项工作运行，并在所有发布版本和各个方面进行测试，例如
容器构建
overcloud 镜像构建
TripleO 部署（独立节点、多节点、场景、OVB）
更新和升级
CLI 设计¶
这是新 tripleo-repos 的预期 cli 设计的抽象草图。
它涵盖了多个地方讨论的大多数需求。
场景 1¶
目标是使用正确的哈希值构建一个仓库，用于集成或组件流水线。
对于此场景
可以传递任何组合的 hash, distro, commit, release, promotion, url 参数
使用 tripleo-get-hash 模块确定 DLRN 构建 ID
使用计算出的 DLRN 构建 ID 创建并添加仓库
场景 2¶
目标是构建任何类型的 yum/dnf 仓库。
对于此场景
使用以下参数的组合构建并添加 yum/dnf 仓库
filename - 保存结果仓库的文件名（必需）
reponame - 仓库名称（必需）
baseurl - 仓库的基本 URL（必需）
down_url - 从中下载仓库文件的 URL（必需/baseurl 互斥）
priority - 结果仓库的优先级（可选）
enabled - 0/1 仓库是否启用或禁用（默认：1 - 启用）
gpgcheck - 是否检查仓库的 GPG 密钥（默认：0 - 不检查）
module_hotfixes - 是否使仓库中的所有 RPM 都可用（默认：0）
sslverify - 是否使用证书使用仓库元数据（默认：1）
type - 仓库类型（默认：generic，其他：custom 和 file）
场景 3¶
目标是启用或禁用特定的 dnf 模块，并安装或删除特定的软件包。
对于此场景
指定
模块名称
要禁用的版本
要启用的版本
要从模块安装的特定软件包（可选）
场景 4¶
目标是禁用一些仓库，删除不再需要的任何关联仓库文件，然后执行系统更新。
对于此场景
指定
要禁用的仓库名称
要启用的仓库名称
要删除的文件
是否执行系统更新
文档影响¶
tripleo-docs 将更新，以指向 tripleo-repos 中新的支持仓库/模块/版本设置工作流程。
需要删除并替换对旧设置来源的引用，例如 tripleo-ansible、tripleo-quickstart 中的发布文件和 repo-setup role，以指向新的工作流程。
