合并计算和中央代理¶
https://blueprints.launchpad.net/ceilometer/+spec/merge-central-and-compute-agents
此前，中央代理从计算代理代码中提取出来，以支持不仅轮询计算指标，还从其他服务和资源收集测量数据。实际上，这两个代理之间的主要区别在于它们发现和轮询资源的方式。在所有轮询器（pollsters）的发现统一后，我们实际上拥有逻辑重复，拥有两个不同的代理，尽管它们都发现和轮询一些资源，然后收集一些指标。
将代理代码合并回去似乎是合乎逻辑的。它们甚至可能使用完全相同的流水线，但仅在控制台脚本参数–polling-namespace上有所不同，以便在实际部署中仍然可以分隔它们。此外，也可以通过–pollster-list脚本参数在此处定义要使用的确切轮询器列表。
问题描述¶
我们拥有两个分离的代理之间的逻辑不匹配，尽管它们可能是同一段代码的一部分，并通过流水线配置。
提议的变更¶
我们需要谨慎地合并计算和中央代理的代码，使用我们已经拥有的统一机制来处理发现和轮询过程。
我们还需要保留设置代理以仅轮询计算或仅轮询中央代理过去使用的指标的能力。基本上，一键安装将满足代理轮询所有可用指标，但生产安装需要这种分离。这将通过添加额外的每个代理的 CLI 脚本参数来实现：–polling-namespace={compute|central|compute,central}（并在添加此处的 ipmi 时也添加）。在这种情况下，运行轮询代理将如下所示
ceilometer-polling –polling-namespace central compute –logfile /var/log/ceilometer/polling.log
此参数将直接传递给代理管理器类，并将定义 setup.cfg 命名空间（ceilometer.poll.central、ceilometer.poll.compute 或两者）以及要加载的可能的轮询器。这将模拟当前的工作流程（并且可能在下一个周期中被弃用）。
此外，此更改将提出一种新的方式来选择轮询代理实例要使用的轮询器 - 通过 CLI 脚本参数 –pollster-list=<轮询器入口点或通配符列表>。在这种情况下，轮询代理运行命令将如下所示
ceilometer-polling –pollster-list image image.size storage.* –logfile /var/log/ceilometer/polling.log
如果同时设置这两个参数，我们需要同时使用它们（可能使用逻辑 AND 运算来确定最终要使用的轮询器列表）。
替代方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
Pipeline 影响¶
无
其他最终用户影响¶
无
性能/可扩展性影响¶
在开发 OpenStack 一键安装的情况下，更好的 RAM 使用率。
其他部署影响¶
Ceilometer 将在节点上运行的服务更少（如果是一键安装），并且我们将拥有更统一的 Ceilometer 安装方式。
对 Ceilometer 包的创建方式以及当前使用它们的部署工具的下游影响。目前，Ceilometer 拥有两个分离的中央和计算代理包（.rpm 和 .deb 都有），并且这些包具有不同的 .service/.upstart 定义，用于启动相应的服务。解决此问题的最简单方法是添加一个新的组合包，并使当前的分离包使用此更改中引入的命名空间，如下所示
s/ExecStart=...ceilometer-agent-compute/ ExecStart=...ceilometer-agent-polling --pollster-namespace=compute/
我们需要更新 puppet-ceilometer 模块并在其中添加支持组合代理的新清单。
开发者影响¶
无
实现¶
负责人¶
- 主要负责人
dbelova <dbelova@mirantis.com>
工作项¶
将中央代理代码合并到当前的计算代理中（ceilometer-polling）。保留 ceilometer-agent-compute 和 ceilometer-agent-central CLI 命令以进行弃用周期。
调查 Tempest 测试的影响，并在需要时提供新的测试。
为 Devstack 提供对新代理方案的支持（用于一键安装和多节点安装）。
调查 Grenade 测试方面。
未来生命周期¶
无
依赖项¶
无
测试¶
此更改需要通过合并的单元测试和集成测试（旧的和可能的新的）进行测试。
文档影响¶
我们需要重写我们的安装指南和通用文档部分，其中包含有关一个代理而不是两个代理的信息。
参考资料¶
无
