风味类别¶
注意
该规范已被 efried 放弃，原因是它自 2015 年以来一直停留在积压目录中。
作为一名操作员，我希望能够为不同的硬件集合定义不同的策略和配额。
举例说明为什么这可能是有益的，考虑一下有些硬件可能运行 libvirt，而有些硬件可能是 ironic 集群的一部分。由于 ironic 管理的裸机硬件不支持诸如救援或附加卷之类的操作，因此希望通过策略禁止在这些硬件上构建的实例执行这些操作，而允许在 libvirt 上的实例执行这些操作。 此外，可能希望仅允许在裸机硬件上构建 x 个实例，而在虚拟化硬件上构建 y 个实例。
可以通过基于风味的“类别”来限定策略和配额来实现这一点。每个风味将被分配一个类别，并且多个风味可以共享同一个类别。继续上述示例，这将允许将裸机风味分组，并将虚拟风味分组。 后续的工作可以允许策略规则按风味类别限定，配额也可以按类别限定。 这可能是像 https://review.openstack.org/#/c/206160/ (一个关于按风味或 AZ 配额的规范) 建立的基础。
还需要一种适当调度风味的方式，可以通过配置计算节点的 advertised capabilities 来实现。 但是，可能还有更好的方法来处理它，可以在未来的规范中讨论。
因此，这里的基本提议是在 db/object/API 中的风味中添加一个字段，以便可以构建限定策略和配额，并且调度程序可以使用它。 我称之为“class”，但也可以称之为 group 或 aggregate 或其他重载的术语，但几乎肯定有一个更好的名称。
Rackspace 目前正在成功地将这个概念用于策略和配额，但我们是在风味扩展规格的基础上构建的。 调度在单元级别处理，因为不同的单元包含不同的硬件类型。 我们希望将此代码上游，但首先需要接受风味类别的初步想法以及我们可以适应我们代码的实现。
问题描述¶
无
用例¶
无
提议的变更¶
让我们以虚拟实例的风味类别为例。 可以根据需要创建不同的风味类别。 例如，可以为裸机实例创建类似于裸机风味类别的类别。
vm_flavor_class {cpu: 100 核, ram: 20 GB, disk: 1 TB}
vm.small {cpu : 2 核, ram : 5 GB, disk: 100 GB, class: ‘vm_flavor_class’}
vm.large {cpu : 2 核, ram : 8 GB, disk: 500 GB, class: ‘vm_flavor_class’}
这意味着最多可以创建 2 个具有 vm.large 配置的 VM 和 1 个具有 vm.small 配置的 VM。 已经提出了一些相关的配额策略引擎工作，以确保对配额分配和预留进行验证和由配额引擎框架管理，但对此的讨论超出了本规范的范围。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
无
- 其他贡献者
alaski, vilobhmm
工作项¶
需要引入一个用于管理风味类别的扩展。
需要引入创建/更新/删除/获取风味类别详细信息的方法。
依赖项¶
无
测试¶
无
文档影响¶
无
参考资料¶
无
历史¶
Liberty 提供的可选部分，旨在每次更新规格说明时描述新的设计、API 或任何数据库模式更新。有助于读者了解随着时间推移发生的变化。
发布名称 |
描述 |
|---|---|
Liberty |
引入 |
Train |
已放弃 |
