Graffiti
我的云里有什么?
我的云里有很多资源。
- 我该如何找到我需要的资源?
- 我该如何描述我拥有的资源?
从最基本的概念来说,Graffiti 的目标是实现跨服务和项目的更好的元数据协作,以便 OpenStack 用户可以利用增强的平台感知能力。
当前状态
Graffiti 项目是在亚特兰大(Juno)OpenStack峰会上提出的。从那时起,这些概念已被采用并实现为多个不同的 OpenStack 项目的一部分。
- Glance 元数据定义目录
- Searchlight
- Nova 功能
- 如 NUMA 拓扑的调度过滤器
- Horizon 功能
- 用于管理目录的管理员 UI
- (管理员 —> 元数据定义) (Kilo)
- 用于将元数据关联到不同资源的窗口小部件
- (下方每个行项目上的“更新元数据”操作)
- admin -> images (Juno)
- admin -> flavors (Kilo)
- admin —> Host Aggregates (Kilo)
- project —> images (Liberty)
- project —> instances (Mitaka)
- 在启动时添加元数据的能力
- project —> Launch Instance (ng launch instance enabled) (Mitaka)
- 用于管理目录的管理员 UI
以下信息提供了关于这些概念起源的大部分背景信息。
概述
我们使用 OpenStack 时遇到的一个挑战是在服务和不同类型的资源之间发现、共享和关联元数据。我们认为这会影响到最终用户和管理员。
对于最终用户,我们认为执行基本任务(如启动实例)对于最终用户来说过于技术化,并且需要对 OpenStack 概念有太多的预先知识。例如,您应该能够仅指定诸如“大数据”或“操作系统系列”之类的类别,然后让系统为您找到引导源,无论它是镜像、快照还是卷。它还应允许更细粒度的过滤,例如过滤您想要软件的特定版本。
对于管理员,我们希望有一种更简单的方法来有意义地协作跨主机聚合、风味、镜像、卷或其他云资源上的属性。
各种 OpenStack 服务提供了将低级资源选择抽象到更高层次的技术,例如风味、卷类型或工件类型。这些资源抽象通常允许使用键值对属性形式的“元数据”来进一步专门化和描述每种资源类型的实例。但是,协作这些属性可能是一个不连接且困难的过程。这通常涉及搜索 wiki 和打开源代码。此外,元数据属性通常需要在多个不同的服务之间关联。随着云规模的增长和管理的资源数量的增加,这变得更加困难。
我们,惠普和英特尔,认为上述两个问题都源于需要一种更好的方法来让用户协作跨服务和资源类型上的元数据。我们启动了一个名为 Graffiti 的项目来探索如何使这对于最终用户来说更容易和更易于访问的想法和概念。请与我们一起加入,共同努力,作为一个社区向前发展!
我们相信我们可以对 Horizon 进行一些立竿见影的改进,但这些改进不能仅通过 Horizon 实现,并且收益应扩展到 API 和 CLI 交互。更好的跨服务协作和元数据一致性应该提供可以被其他项目(如调度、预留、编排和策略执行)利用的好处。
术语说明
我们认为“元数据”这个术语有些难以接近,因此我们一直在探索“能力”的概念。能力可以简单地被认为是具有或不具有属性的命名“标签”。这个想法是用户可以简单地将能力“标记”到各种云资源上,例如镜像、卷、主机聚合、风味等。对于最终用户来说,数据存储的确切机制由系统处理。
演示视频
为了帮助解释项目的想法,我们有一个快速演示视频,演示了在 POC 代码下运行的概念。请看一看!
使用概念
- 加载您的元数据定义(有时称为属性、标签或能力)
- 到中央元数据目录
- 使用您的标签和能力更新云中的资源
- 让用户使用您想要的标签和能力找到资源
设计概念
关于 Architecture 页面的其他架构概念。
Juno Summit 设计会议
POC 演示回顾ː ̽ * https://www.youtube.com/watch?v=Dhrthnq1bnw
IRC
各个功能由以下 IRC 频道中的团队维护,位于 Freenode 上。
#openstack-searchlight #openstack-horizon #openstack-glance
开发
- Apache 2.0 开源
- Graffiti POC API 服务源代码仓库 - 停止维护(请参阅 Glance、Horizon、Searchlight)