已废弃：Glance 保护属性
这是尝试整理 etherpad 中的一些当前想法：https://etherpad.openstack.org/public-glance-protected-props。这是一个正在进行中的工作，欢迎评论/编辑。
为了实现 Glance 保护属性，我们需要做以下事情
- 弄清楚什么是“保护属性”
- 显示保护属性
- 保护保护属性
- 配置保护属性
- 对保护属性进行 CRUD 操作
- 存储保护属性
- Nova 对保护属性的使用
定义“保护属性”
Stuart 和 Iccha 在 etherpad 中对此做了很好的工作。目前，Glance 具有可以放在镜像上的两组属性
- 核心属性（例如，名称、ID、min_ram）
- 用户属性（任意用户可指定的键/值对）
我们建议一个新的类别
- 保护属性
这些将是任意的键/值对，但将由云提供商（即 Glance 管理员）指定。“保护”这些属性在于 Glance 管理员可以配置对最终用户的访问控制，例如，某些属性可以是只读的，某些属性可以隐藏（仅供管理员读取/写入），某些属性可以由最终用户修改。因此，它们类似于用户属性，因为它们在 Glance 发布时是未知的，并且它们类似于核心属性，因为它们在所有镜像上都具有相同的名称（和保护）。
我们认为将这作为一个单独的属性类别，而不是强行塞入核心属性或用户属性中更有意义。当前镜像的消费者（例如，Nova）依赖于核心属性，所以我们不想去修改它们。至于用户属性，它们目前肯定是有用的，我们不确定是否有一个令人信服的使用案例来允许镜像所有者以我们希望允许云提供商保护保护属性的方式来保护这些属性，并且我们不想为了弄清楚如何将保护扩展到用户属性而延迟保护属性的实现。（一旦保护属性实现，可以重新审视这个问题。）因此，这三个属性类别在概念上是分开的；目前看来，以不同的方式实现它们是合理的。无论如何，这就是我们目前的想法。
显示保护属性
镜像响应可能如下所示
"image" : {
"core1" : "value",
"core2" : "value"
},
"metadata" : {
"key1" : "value",
"key2" : "value"
},
"system" : {
"pp1" : "only-a-glance-admin-can-see-me",
"pp2" : "i-am-read-only-for-non-admins"
}
}
核心*是核心属性，metadata 字段包含用户属性，保护属性在 system 字段中。我们认为将保护属性与其他属性分开是有意义的，这反映了它们的用途，并且也更不会让最终用户感到困惑。
保护保护属性
(一旦我们弄清楚如何配置保护属性以及它们的操作方式，就必须实现实际的保护。)
配置保护属性
我们需要弄清楚
- 如何定义特定 Glance 安装的保护属性
- 目前的想法是在部署时完成；由于这些是某种“系统”属性，云提供商应该提前知道它们是什么
- 可以使用 JSON schema 来实现，但这*不是*最终用户在 image-schema 响应中看到的 schema
- Glance v2 目前正在使用 JSON schema v3，所以如果我们选择 JSON schema 路线，我们将不得不切换到 JSON schema v4,[1] 这允许你扩展 schema 关键字（因此我们可以添加一个“protections”关键字，该关键字允许你定义属性上的保护）。
- 如何显示此信息（即，不显示键/值本身，而是显示键是什么以及它们上的保护是什么）
- 如何将此信息合并到 v2 image-schema 响应中（例如，镜像 schema 的最终用户消费者应该知道示例上面的属性 pp2 存在，但不应该知道属性 pp1；但是，Nova 应该知道 pp1 和 pp2）
对保护属性进行 CRUD 操作
我们需要弄清楚用于在特定镜像上设置这些属性值的 API 调用是什么样的。
存储保护属性
它们将进入数据库的某个地方，是在它们自己的表中还是与用户属性一起？我们不想减慢镜像详细信息响应的速度，但我们也需要知道应用镜像详细信息请求的用户如何应用保护。
Nova 对保护属性的使用
(这可能超出了此蓝图的范围，但值得思考。由于这些是类型为系统属性，因此我们希望 Nova 在启动实例时将其中一些属性传播到实例是有意义的。因此 Nova 必须能够读取保护属性。Nova 是否也必须尊重保护，例如，隐藏的镜像属性是否会变成隐藏的服务器属性？)
