Graffiti/Dictionary

< Graffiti/Architecture

字典 API

一个通用的 API，供服务、管理员和用户发现和共享他们的元数据词汇。这是创建关于如何描述云提供的各种能力达成共识的基础。基本思想是它可以支持非结构化属性和结构化/分层元数据，形式为“能力类型”。字典中的所有定义都将“命名空间化”。

扩展上下文覆盖

这提供了 Graffiti 概念与 Graffiti 组件的覆盖。

定义元数据

挑战

我们发现暴露 OpenStack 今天使用的元数据存在一些有趣的挑战。

• 属性键通常设置为单个通用术语。它只有在协作使用该属性的服务上下文中才有意义。当在其他服务的上下文中使用时，通用术语可能会冲突。在不同的上下文中，它的含义和允许的值可能非常不同。
  • 例如，属性“architecture”（架构）用于描述计算主机 hypervisor 必须支持的 CPU 架构。Nova 计算调度服务是处理此属性最关心的服务，但该属性可以放置在镜像或可引导卷上（通过 volume_image_metadata）。如果将此属性应用于不同类型的资源，则该术语可能不适用或可能具有不同的含义。

• 不同的组织或服务提供商可能希望
  • 限制在 UI 中对属性的可见性
  • 将相似的属性分组
  • 为他们的用户提供替代表示形式。
    • 包括描述该属性的本地化字符串

解决方案概念：命名空间和能力类型

命名空间

• 包含属性定义
• 包含能力类型定义（稍后介绍）
• 与可以应用它的资源类型相关联
• 可以向不同的项目公开
• 定义如何将其属性转换为扁平属性
  • 例如，只需放置属性名称，或包含其他限定信息（例如命名空间和能力类型）

属性

单个属性定义应基于 JSON Schema。

能力类型

我们认为“元数据”这个术语有点难以接近，所以我们一直在探索“能力”的概念。能力可以简单地被认为是一个命名的“标签”，它可能包含也可能不包含属性。想法是用户可以简单地将能力“标记”到各种云资源上，例如镜像、卷、主机聚合、flavor 等。对于最终用户来说，数据存储的确切机制由系统处理。

有时，该能力用于描述资源提供的内容（例如，一个镜像可以提供“Apache”，而 flavor 或主机聚合等资源可以提供 GPU 加速或某种程度的信任证明等能力）。同样，资源可以指定使用它所需的条件，例如需要能够提供硬件级 AES 加密支持的主机镜像或可引导卷。

能力类型如下

• 描述云资源可能提供的一种能力类型的元数据模式
  • 例如，“CENTOS”可能是一种能力类型

• 定义可观察属性的结构
  • 属性的名称、数据类型和允许的值（使用 JSON schema 格式）
    • 例如，os_distro 属性设置为 "centos"

• 分层
  • 可以从父能力类型继承属性
  • 例如，CENTOS 是一种操作系统，所有操作系统都有一个名为 os_version 的属性

• 包含属性
  • 单独定义属性并在 1 到多个能力类型中引用它们
    • Graffiti 将解析引用的属性并将它们“扁平化”到多个定义提供程序中，以便于消耗

• 由需求引用
  • 例如，我的应用程序需要 CENTOS

• 由 命名空间限定
  • 在命名空间内唯一命名
    • 你对“Classified”（分类）的定义与我的不同，所以我们同意意见不一致
  • RBAC 在命名空间上完成，而不是在单个类型上
  • 能力类型可以从其他命名空间中的类型派生