TripleO Ceph Ganesha 集成 Manila¶
https://blueprints.launchpad.net/tripleo/+spec/tripleo-ceph-ganesha
从 Octopus 版本开始，Ceph 拥有自己的 day1 工具 cephadm 和 day2 工具 orchestrator，它们将取代 ceph-ansible。
在 Wallaby 周期中，TripleO 将不再使用 ceph-ansible 进行 Ceph 部署，而是使用 cephadm [2]，如 [1] 中所述。Ganesha 值得特别关注，因为对于它的部署，我们将使用 cephadm 中的特殊功能 [2]，这些功能旨在在 Ceph 集群为外部集群时独立部署 Ganesha 服务。
问题描述¶
在 TripleO 中，我们支持在 Ceph 集群由 TripleO 管理和 Ceph 集群不由 TripleO 管理的情况下部署 Ganesha。
当 Ceph 集群不由 TripleO 管理时，Ganesha 服务必须独立部署；也就是说，不使用任何额外的核心 Ceph 守护进程，而应配置它以使用外部 Ceph MON 和 MDS 守护进程。
提议的变更¶
概述¶
一个 ansible 任务将触发 cephadm [2]，并带有特殊参数，以便启动一个独立的 Ganesha 容器，并将以下内容提供给它：
使用 tripleo-ceph-client [3] 角色生成的 Ceph 集群配置文件
用于与 MDS 交互的 Ceph 集群密钥环
带有指向要使用的 Ceph 配置/密钥环的指针的 Ganesha 配置文件
然后，容器将由 pacemaker 控制，就像今天一样，并重用今天管理 ceph-ansible 创建的 ceph-nfs systemd 服务的相同代码。
替代方案¶
讨论过并重用现有的 ceph-ansible 角色来处理 ceph-nfs，但最终被放弃了，因为这将把 Ganesha 部署任务的所有权转移到 TripleO 中，而我们的目标是让所有权保持在具有主题专业知识的地方，即 Ceph 部署工具中。
安全影响¶
没有，TripleO 已经用于生成 Ceph 集群配置和密钥环的相同代码将被使用。
升级影响¶
将添加一些升级任务，这些任务将停止并删除预先存在的 ceph-nfs 容器和 systemd 单元，以清理系统中的 ceph-ansible 管理资源。
其他最终用户影响¶
没有，现有的输入参数将被重用以驱动新的部署工具。
性能影响¶
没有更改。
其他部署者影响¶
对用户没有影响。
开发人员影响¶
Ganesha 配置文件将使用特定的 tripleo-ceph 任务生成，而以前，使用 ceph-ansible 时，它是通过 ceph-ansible 本身创建的。
实现¶
依赖 ceph-ansible 的现有实现将保留在树中至少一个弃用周期。通过重用现有的 Heat 输入参数，我们应该能够通过仅切换部署时使用的环境文件，以透明的方式使 Ganesha 部署使用 ceph-ansible 或新的角色。
部署流程¶
本规范中描述的部署和配置将在 openstack overcloud deploy 之前发生，如 [1] 中所述。这与 ceph-ansible 在 step2 期间用于配置这些服务的方式一致。但是，使用 Ganesha 的 Manila 配置的某些部分仍然会在运行 openstack overcloud deploy 时发生。这是因为 Ganesha 和 Manila 的一些配置需要在 step 5 中进行。因此，将更新诸如 environments/manila-cephfsganesha-config.yaml 之类的文件，以触发新的必需操作。
负责人¶
fmount
fultonj
gfidente
工作项¶
创建一组任务，以在 overcloud 节点上部署 Ganesha 配置文件
创建一组任务，以使用特殊参数触发 cephadm
依赖项¶
tripleo-ceph 规范 [1]
测试¶
由于我们只有一个网络，而对于 Ganesha，我们需要至少两个网络，一个用于将其连接到 Ceph 公共网络，另一个用于将 NFS 代理服务暴露给租户，因此目前无法进行测试。
这是一个设计决策，使用 NFS 代理为 CephFS 增加的价值之一是实现租户访客和实际 Ceph 集群之间的网络隔离。
这种限制并非来自迁移到 cephadm [2]，而是始终存在的；事实上，强制使用两个隔离网络的代码位于 TripleO 中，而不是 Ceph 工具本身。我们可能会在未来重新审视这一点，但这并非本规范的目标。
文档影响¶
无需对 TripleO 文档进行任何更改。
