卷类型中的用户可见信息¶
https://blueprints.launchpad.net/cinder/+spec/user-visible-information-in-volume-types
卷类型用于在创建卷时找到合适的后端。但它们也意味着一些卷的配置,这些配置对于需要从各种卷类型中选择的任何人来说都很好地了解。
问题描述¶
当非管理员用户创建卷时,他们希望看到有关卷类型的各种信息。其中一些信息在查看卷类型时已经对用户可见(例如,multiattach)。其他信息要么根本不可用,要么对非管理员用户不可见。这在尝试创建卷时选择合适的卷类型时是一个问题。
用例¶
用户希望看到的信息首先是:1. 卷类型是否可用于创建加密卷 2. 卷类型是否创建复制的卷,无论是通过 Cinder 还是通过配置的后端(如 ceph)
第一条信息来自卷中的加密类型,而该加密类型仅对管理员可访问。第二条信息可以设置并在卷类型的 extra_specs 中直接查看,或者间接是后端配置的一部分。
可能还有更多用例,应该受益于允许管理员以统一的方式向卷类型添加某些面向用户的的信息的解决方案。
由于越来越多的工具自动创建 IaaS 资源,这些信息应该以统一的方式访问,并且最好在客户端中用于过滤合适的卷类型。
提议的变更¶
为了让操作员添加对用户可见且机器可读的信息,我们在卷类型对象中引入了一个名为“metadata”的新字段。这将包括 API 更改,以解决卷类型的新视图,以及一个新的 API 端点,用于将信息作为键值对设置到此 metadata 字段。还需要一个用于这些 metadata 的新数据库表。
该表将包含卷类型 ID、键、值、主键 ID 以及创建、更新和删除的 metadata 的列。数据库的升级路径可能如下所示
def upgrade():
op.create_table(
'volume_type_metadata',
sa.Column('created_at', sa.DateTime),
sa.Column('updated_at', sa.DateTime),
sa.Column('deleted_at', sa.DateTime),
sa.Column('deleted', sa.Boolean),
sa.Column('id', sa.Integer, primary_key=True, nullable=False),
sa.Column(
'volume_type_id',
sa.String(36),
sa.ForeignKey(
'volume_types.id',
name='volume_type_metadata_ibfk_1',
),
nullable=False,
index=True,
),
sa.Column('key', sa.String(255)),
sa.Column('value', sa.String(255)),
mysql_engine='InnoDB',
mysql_charset='utf8',
)
在 API 中,将有两个字段:“extra_specs”和“metadata”,在 CLI 中,这些字段将是“properties”和“metadata”。后者可能会让用户感到困惑,因此需要为 API 和 CLI 提供文档,以阐明对每个字段的期望。此更改的限制是,并非用于调度目的的键值对仍然可以放入 properties/extra_specs 中,稍后会导致调度过程中的错误。
在第二阶段,可以添加 metadefs 来标准化某些键,例如“encryption_type”或“replicated”。
备选方案¶
我们评估了使用已经存在的面向用户的“extra_specs”字段。管理员已经可以在此处设置键值对,并且用户可见的 extra_specs 可以在此字段中看到。但这会导致卷调度器出现问题,因为调度器在查找适合卷的后端时会评估 extra_specs 表中的 EVERY 输入。虽然可以通过白名单或黑名单方法解决此问题,但维护和评估这些列表对用户来说非常不透明。总体而言,这种方法可能会导致用户更加困惑。
另一种选择是单独处理用例
1. 关于卷类型是否创建加密卷的信息可以在列出/显示卷类型的 API 调用中根据加密类型是否存在来计算。该信息将显示在“properties”字段中。这将是一个非常小的补丁,但无法解决其他将受益于面向用户信息的用例。 2. 在卷类型表中创建一个额外的字段,该字段在创建或删除加密类型时自动设置。这需要更改数据库和更改卷类型的视图。 3. 了解不同的驱动程序如何处理内部可配置的复制,以及是否有方法让 OpenStack 知道这一点并将其传播给用户。这很难实现,甚至可能无法实现,除非操作员配置了后端和卷类型提供输入。 4. 可以放宽加密类型的策略,让用户不仅可以看到卷类型是否具有加密类型,还可以看到用于加密的算法和提供程序。这可能会产生安全影响。
所有这些选项都无法解决在卷类型中提供可靠的面向用户信息的总体问题。它们也不会解决操作员能够将并非用于调度目的的键值对添加到卷类型 extra specs 中的问题。
数据模型影响¶
有必要创建一个新的表 metadata,其工作方式与 extra_specs 表类似。由于目前卷类型中没有用户可见的信息,因此最初一个空表就足够了。
为了遵守从以前的 OpenStack 版本升级的情况,需要检查所有卷类型,并且对于具有关联加密类型的卷类型,需要根据所选选项在数据库中设置加密参数。这不应该通过 API 调用来完成,而是需要直接访问 DB,因为应该禁止更改正在使用的卷类型的 metadata。
REST API 影响¶
需要向卷类型的视图添加一个新字段。对于该字段,需要新的 API 调用
一个 POST 方法来设置新的键值对
一个 DELETE 方法来删除一个键值对。
可选地,一个 GET 方法来显示一个键值对。
可选地,为 GET 卷类型方法添加针对某些 metadata 的过滤功能
卷类型 metadata 将像卷类型描述一样处理,也就是说,我们将允许修改它,即使卷类型正在使用。我们可以这样做,因为卷类型 metadata 仅是描述性的,而卷类型 extra_specs 会影响调度器。
此外,创建卷类型 API 调用应该能够处理新 metadata 字段的键值对。
安全影响¶
此更改将暴露一个布尔值,该值显示卷类型在创建时是否会加密卷。
Active/Active HA 影响¶
这不应影响 Cinder 的 Active/Active HA 支持。
通知影响¶
当对数据库条目进行创建或删除时,将会有额外的通知。它们将像 extra_specs 的通知一样运行。每当从新的 metadata 字段/数据库创建或删除键值对时,都会发送这些通知。
其他最终用户影响¶
此更改可能会导致用户希望在 openstack volume type list –metadata key=value 中使用过滤机制来处理上述两种用例。
性能影响¶
获取卷类型及其详细信息的 API 调用将对新的 metadata 表进行额外的查询。
其他部署者影响¶
具有关联加密类型的旧卷类型需要设置潜在的新数据库条目。这不能通过 volume type set 命令完成,而是必须手动或使用脚本写入数据库,为所有受影响的卷类型设置正确的条目。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Josephine Seifert (josei)
- 其他贡献者
无
工作项¶
在 Cinder 数据库中添加一个“volume_type_metadata”表
添加卷类型 metadata 字段的新 API 端点,并在创建卷类型时添加在 metadata 字段中创建新的键值对的可能性
为新的 API 调用添加 CLI/SDK 中的支持
依赖项¶
没有依赖关系。
测试¶
创建卷类型的测试用例可能会更新,以集成添加 metadata 键值对的功能。
文档影响¶
需要文档来区分 extra specs 和用户可见信息的处理方式。