UnifiedGuestAgent

Unified Guest Agent

代理是在 Glance 镜像上安装的一段 Python 软件。它应该配置为在实例启动时启动。启动后，它会监听并执行访客（实例）内部的控制器命令。它可以

在访客上执行 shell 命令
在访客和外部之间移动文件
从访客向指定的主机/端口发送 http 请求
以“调用”和“广播”两种方式执行上述操作
- “调用”和“广播”的区别在于，“调用”调用在操作完成后返回，并且还可以返回操作的结果。“广播”调用以“发射即忘”的方式行事——一旦操作开始就返回。

目标受众/贡献者是那些需要在 VM 内部执行操作，而 cloud-init 对此不足的项目。这包括：多步骤软件安装、在扩展/需求时重新配置、传递用户命令等。

该倡议有两个目标

以下项目的人员可能会感兴趣：Heat、Savanna、Trove、Murano 和 Solum。

关键架构特性是

支持不同的访客操作系统
支持不同的传输方式
- 硬件部署的 MQ / Marconi MQ / http / ssh / 还有什么？
API 的各个部分可以在不同的项目之间重用。
- 意图不是为所有项目提供单个 API，而是提供一组可以组合成 API 的构建块。这样可以保持代理的大小较小，并且允许添加特定于领域的 API 作为单独的“块”。

传输的任务是提供一种安全地将消息从控制器传递到访客以及反向传递的机制。支持各种传输的需求源于 OpenStack 部署和要求的多样性。不同的传输方式提供不同的功能，并对云提出不同的要求。这在示例中可以更好地体现

硬件部署的 MQ 需要云端具有队列服务器，控制器和 VM 都可以访问。
Marconi MQ 需要在云端部署 Marconi，但目前尚未广泛采用。
http 需要部署一个 http 端点，并且 VM 可以访问。代理可以轮询该端点以获取任务。“调用”操作需要端点接受来自 VM 的数据（通过 POST 请求？）。
ssh 是一个特殊情况。它不需要在访客上安装代理，而是该库将通过 ssh 在访客上调用命令。但它需要控制器直接访问访客 VM，而这并非总是如此。

(devdatta-kulkarni：这个选项可能会在控制器端遇到可扩展性问题。)

自最初的提案以来，已经进行了一系列讨论

- http://lists.openstack.org/pipermail/openstack-dev/2013-December/021476.html

许多人表达了他们的意见，但没有达成共识。以下 etherpad 试图总结提出的选项： https://etherpad.openstack.org/p/UnifiedGuestAgent

- http://lists.openstack.org/pipermail/openstack-dev/2014-January/024968.html

关于 os_collect_config 迁移到 oslo.messaging 的公告

- http://lists.openstack.org/pipermail/openstack-dev/2014-March/029194.html

讨论表明，许多人认为 oslo.messaging 不适合代理传输，因为很难用它提供足够的租户隔离。与此同时，Marconi 默认情况下提供了这一点。