移除 os-hypervisors API 中的资源信息¶
https://blueprints.launchpad.net/nova/+spec/modernize-os-hypervisors-api
自 nova 早期以来,os-hypervisors API 就一直存在。 在那些太平盛世的日子里,它提供了一种很好的方式来快速总结部署中各个计算节点的资源使用情况。 然而,如今它已经名不副实。 它返回的更详细的信息是特定于超visor的,并且经常不正确,尤其是在 CPU pinning 或基于文件的内存等高级功能下。 随着 placement 提升到它应有的位置,成为(几乎)所有资源的主宰,os-hypervisor API 需要显著精简。
问题描述¶
本规范的大部分内容集中在对 /os-hypervisors/detail API 的更改上。 考虑一下典型的 GET /os-hypervisors/detail 调用输出,摘自 API 参考 [1]
{
"hypervisors": [
{
"cpu_info": {
"arch": "x86_64",
"model": "Nehalem",
"vendor": "Intel",
"features": [
"pge",
"clflush"
],
"topology": {
"cores": 1,
"threads": 1,
"sockets": 4
}
},
"current_workload": 0,
"status": "enabled",
"state": "up",
"disk_available_least": 0,
"host_ip": "1.1.1.1",
"free_disk_gb": 1028,
"free_ram_mb": 7680,
"hypervisor_hostname": "host1",
"hypervisor_type": "fake",
"hypervisor_version": 1000,
"id": 2,
"local_gb": 1028,
"local_gb_used": 0,
"memory_mb": 8192,
"memory_mb_used": 512,
"running_vms": 0,
"service": {
"host": "host1",
"id": 6,
"disabled_reason": null
},
"vcpus": 2,
"vcpus_used": 0
}
],
"hypervisors_links": [
{
"href": "http://openstack.example.com/v2.1/6f70656e737461636b20342065766572/os-hypervisors/detail?limit=1&marker=2",
"rel": "next"
}
]
}
这里的字段大致分为三类:有用但重复在摘要(非详细)视图中,有用且独特于详细视图,以及无用。 首先,有用的但重复的字段。 这些应该保留
idstatusstatehypervisor_hostname
接下来,有用且独特于详细视图的字段。 这些也应该保留
host_iphypervisor_typehypervisor_version服务
最后,无用的字段。 它们无用的原因各不相同,如下所述,但都应该移除
current_workload这跟踪“超visor负责的任务数”,并且“将等于或大于系统上活动 VM 的数量(当 VM 正在删除并且超visor仍在清理时,可能会更大)” [2]。 此信息可以通过列出活动和已删除的实例轻松计算。
cpu_info表面上看很有用,但对调度目的而言只有 CPU 架构和 CPU 功能是相关的,所有这些都已由 placement trait 请求处理。 topology 字段是一种怪异之处,可能本不应该添加。 它不能用于调度,并且可能不正确,因为它不反映离线 CPU 或由于配置而对 nova 不可用的 CPU,并且它不能处理非均匀 CPU topology,例如一个插槽上的核心比另一个插槽上的核心更多。 如果操作员想要此信息,他们可以像识别例如 PCI 设备或存储设备一样简单地检查主机。
free_disk_gb,local_gb,local_gb_used💩 如果使用共享存储,几乎总是错误的,并且不考虑过度承诺。 使用 placement。
disk_available_least反映了如果主机上的所有实例都使用其所有已分配的磁盘空间,超visor 上估计的可用磁盘空间。 如果启用了磁盘过度承诺,或者实例被强制迁移到主机,绕过调度器,则此值可能会变为负数。 此值难以使用,并且经常被最终用户误解。
free_ram_mb,memory_mb,memory_mb_used不考虑过度承诺或非默认页面大小。 使用 placement。
vcpus,vcpus_used不考虑过度承诺或 PCPU 库存。 使用 placement。
running_vms可以通过按主机过滤运行的实例轻松找出(仅限管理员,就像此 API 一样)。
除了对 /os-hypervisors/detail API 的更改之外,还有另外两个 API 似乎已经过时:/os-hypervisors/statistics,它提供上述信息的摘要,以及 /os-hypervisors/{hypervisor_id}/uptime,它提供了一个 API 来获取单个数字。 前者可以完全删除以支持 placement,而后者可以替换为 /os-hypervisors/{hypervisor_id} API 上的新 uptime 字段。
用例¶
作为用户,我不想看到从我的 API 报告的误导性信息。
提议的变更¶
移除 /os-hypervisors/detail API 输出中的资源相关字段,并完全移除 /os-hypervisors/statistics API。
备选方案¶
我们可以记录这些 API 不正确的性质。 这不太理想,因为人们不会阅读文档。
数据模型影响¶
无。
REST API 影响¶
从新的 API 微版本开始,/os-hypervisors/detail API 将不再在其响应中包含以下字段:cpu_info, free_disk_gb, local_gb, local_gb_used, disk_available_least, free_ram_mb, memory_mb, memory_mb_used, vcpus, vcpus_used 和 running_vms。
/os-hypervisors/statistics API 包含上述字段的摘要信息,将被完全删除,在新 API 微版本上返回 HTTP 404(未找到)。
由 /os-hypervisors/{hypervisor_id}/uptime API 显示的 uptime 信息不值得拥有自己的 API,并且在新 API 微版本上也将返回 HTTP 404(未找到)。 此信息将通过 /os-hypervisors/{hypervisor_id} API 上的新 uptime 字段提供。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
客户端需要更新。 引用这些 API 的文档需要更新,并建议查看 placement 或其他 API。 至于对 /os-hypervisors/detail API 的更改
可以使用
openstack resource provider inventory list和openstack resource provider usage show的组合来识别free_disk_gb,local_gb,local_gb_used,free_ram_mb,memory_mb,memory_mb_used,vcpus和vcpus_used值。 例如$ openstack hypervisor show devstack-1 \ -c local_gb -c local_gb_used -c free_disk_gb \ -c memory_mb -c memory_mb_used -c free_ram_mb \ -c vcpus -c vcpus_used +----------------+-------+ | Field | Value | +----------------+-------+ | local_gb | 18 | | local_gb_used | 1 | | free_disk_gb | 19 | | memory_mb | 16035 | | memory_mb_used | 1024 | | free_ram_mb | 15011 | | vcpus | 12 | | vcpus_used | 1 | +----------------+-------+ $ openstack resource provider inventory list bde27f9d-1249-446f-ae14-45f6ff3e63d5 +----------------+------------------+----------+----------+----------+-----------+-------+ | resource_class | allocation_ratio | min_unit | max_unit | reserved | step_size | total | +----------------+------------------+----------+----------+----------+-----------+-------+ | VCPU | 16.0 | 1 | 12 | 0 | 1 | 12 | | MEMORY_MB | 1.5 | 1 | 16035 | 512 | 1 | 16035 | | DISK_GB | 1.0 | 1 | 19 | 0 | 1 | 19 | +----------------+------------------+----------+----------+----------+-----------+-------+ $ openstack resource provider usage show bde27f9d-1249-446f-ae14-45f6ff3e63d5 +----------------+-------+ | resource_class | usage | +----------------+-------+ | VCPU | 1 | | MEMORY_MB | 512 | | DISK_GB | 1 | +----------------+-------可以使用
openstack server list --host <HOST>按主机过滤实例来识别running_vms值。 例如$ openstack hypervisor show devstack-1 -c running_vms +-------------+-------+ | Field | Value | +-------------+-------+ | running_vms | 1 | +-------------+-------+ $ openstack server list --host devstack-1 -c ID -f yaml | wc -l 1
注意
这不是 1:1 的替换,因为
running_vms设置将跟踪超visor 上运行的所有 VM,包括那些不由 nova 管理的 VM。 然而,在超visor 上拥有不由 nova 管理的 VM 被认为是一种错误配置,并且与调度目的无关。可以使用
openstack resource provider trait list检查cpu_info.arch和cpu_info.features值,这些值作为 traits 发布。 例如$ openstack hypervisor show devstack-1 -f yaml -c cpu_info cpu_info: '{"arch": "x86_64", "model": "IvyBridge-IBRS", "vendor": "Intel", "topology": {"cells": 2, "sockets": 1, "cores": 3, "threads": 2}, "features": ["xsaveopt", "erms", "ssbd", "arch-capabilities", "nx", "cx16", "ht", "mca", "tsc-deadline", "amd-ssbd", "pcid", "pse", "ss", "syscall", "md-clear", "tsc_adjust", "mmx", "rdtscp", "f16c", "fxsr", "lahf_lm", "spec-ctrl", "smep", "pse36", "vme", "de", "sse", "xsave", "clflush", "cmov", "msr", "pat", "aes", "hypervisor", "mtrr", "sep", "fsgsbase", "tsc", "sse2", "apic", "pdpe1gb", "cx8", "umip", "vmx", "pae", "skip-l1dfl-vmentry", "popcnt", "ssse3", "avx", "pclmuldq", "x2apic", "lm", "stibp", "fpu", "ibpb", "rdrand", "sse4.1", "pni", "pge", "sse4.2", "pschange-mc-no", "mce", "arat"]}' $ openstack --os-placement-api-version 1.8 \ resource provider trait list bde27f9d-1249-446f-ae14-45f6ff3e63d5 | grep CPU | HW_CPU_X86_AMD_SVM | | HW_CPU_X86_SSE2 | | HW_CPU_X86_SSE | | HW_CPU_X86_SVM | | HW_CPU_HYPERTHREADING | | HW_CPU_X86_MMX |disk_available_least,cpu_info.model,cpu_info.vendor和cpu_info.topology值与调度无关,因此在 placement 或另一个 API 中没有直接的替代方案。 但是,可以通过检查主机来识别它们。
Horizon 需要更新以与 placement 通信或使用旧的微版本的此 API。 同样,任何使用 /os-hypervisors/{hypervisor_id}/uptime API 的用户都需要使用 /os-hypervisors/{hypervisor_id} API。
性能影响¶
无。
其他部署者影响¶
无。
开发人员影响¶
无。
升级影响¶
无。
实现¶
负责人¶
- 主要负责人
stephenfinucane
- 其他贡献者
无
功能联络人¶
无。
工作项¶
在新微版本中更新 API。
更新文档以删除对这些已弃用 API 的引用。
更新客户端以反映弃用情况。
依赖项¶
无。
测试¶
单元和功能测试。 Tempest 测试需要更新为限制于最新的微版本以支持这些 API。
文档影响¶
需要删除或更新对 API 的引用。
参考资料¶
无。
历史¶
发布名称 |
描述 |
|---|---|
Wallaby |
引入 |
Wallaby |
已更新以删除对策略更改的引用,这些更改已被推迟。 |