结构化元数据

Launchpad 条目：NovaSpec:foo 或 SwiftSpec:foo
创建:
贡献者:

总结

支持在 glance 元数据中存储结构化数据。目前 glance 元数据是简单的键值对。因此，需要支持结构化数据（列表和字典）。

发布说明

对最终用户无可见变化。此功能对于从卷启动功能是必要的。主要变化将在 glance API 上进行。因此 Glance 客户端可能会看到变化。

原理

为什么需要结构化数据？

为了在 nova 中支持从卷启动，关于块设备映射的信息存储在镜像元数据中，而镜像元数据存储在 glance 中。也就是说，来宾设备上的哪个设备对应哪个 nova 卷/临时设备。所以它是一个字典列表。

元数据示例

metadata = {'name': 'fake public image',
           'properties': {
               'mappings': [
                   {'device_name': '/dev/sda1',
                    'snapshot_id': 0x12345678,
                    'delete_on_termination': False},
                   {'device_name': '/dev/sda2',
                    'no_device': True}],
               'block_device_mapping':  [
                        {'virtual': 'ami', 'device': 'sda1'},
                        {'virtual': 'root', 'device': '/dev/sda1'},

                        {'virtual': 'swap', 'device': 'sdb1'},
                        {'virtual': 'swap', 'device': 'sdb2'},

                        {'virtual': 'ephemeral0', 'device': 'sdc1'},
                        {'virtual': 'ephemeral1', 'device': 'sdc2'}]}}

用户故事

前提条件

设计

有几种可能的实现方案。

Glance 不了解其值。客户端应该进行序列化/反序列化。当 Glance 客户端想要存储时，客户端必须通过 json.dumps 转换为文本块。
- 优点
  - 简单，无需更改 glance
缺点
- 客户端需要了解数据结构。
- 排除 glance 过滤能力
Glance 进行序列化/反序列化
- 优点
  - 简单，无需更改客户端
缺点
- glance 需要了解数据结构。
- 排除 glance 过滤能力
Glance 理解结构化数据
- 优点
  - 允许 glance 过滤能力
缺点
- 实现起来比较复杂（poc 补丁已经可用）
将结构化数据作为 Glance 扩展实现，用于额外的元数据。映射应该作为注册上的新中间件，甚至作为扩展来实现。

  PUT /images/<ID>/container-format

  with a body of something like:

  'format': {
    'mappings': [
                   {'device_name': '/dev/sda1',
                    'snapshot_id': 0x12345678,
                    'delete_on_termination': False},
                   {'device_name': '/dev/sda2',
                    'no_device': True}
    ],
    'block_device_mapping': [
                   {'virtual': 'ami', 'device': 'sda1'},
                   {'virtual': 'root', 'device': '/dev/sda1'},
                   {'virtual': 'swap', 'device': 'sdb1'},
                   {'virtual': 'swap', 'device': 'sdb2'},
                   {'virtual': 'ephemeral0', 'device': 'sdc1'},
                   {'virtual': 'ephemeral1', 'device': 'sdc2'}
    ],
  }

 And then, the extension/middleware can store specific information about the
 container in separate tables in the database that can be queried using a more
 specific API than the very limited custom key/value properties we currently
 have.

优点
- 允许 glance 过滤能力
- 不影响现有代码
- 干净的实现
- 未来可扩展。

     When we'd like to add other structured metadata in the future, it would be easy as this is the model case.

缺点
- 实现起来需要更多努力

实现

本节应描述实施所讨论更改的行动计划（“如何”）。可以包括诸如

UI 变更

应涵盖对 UI 的要求更改或实施此功能的特定 UI

代码变更

代码变更应包括需要更改的内容的概述，并且在某些情况下甚至包括具体细节。

迁移

包括

数据迁移（如果有）
从旧 URL 到新 URL 的重定向（如果有）
如何引导用户使用新的操作方式（如果需要）。

测试/演示计划

这不必在规范接近 Beta 之前添加或完成。

未解决的问题

这应该突出显示需要在进一步的规范中解决的任何问题，而不是规范本身的问题；因为任何存在问题的规范都无法获得批准。

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。