ZStack中的标签不仅帮助用户聚集资源,也帮助控制软件行为。ZStack有一套完整的规范,用以定义标签的类别、形式和用法。除了用户外,插件也可以创建自己的标签,以记录元数据和拓展现有的资源属性;通过这些手段,标签可以帮助插件引入新的特性,而不改变ZStack的数据库结构,消除了在软件升级对数据库迁移的需求。
动机
随着云中资源的不断增长,用户可能会想要有一种方式,使用人类可读的标签,去分组相似的资源。举个例子,所有Web服务器的虚拟机都可以有一个标签’web-tier-vm’,这样可以从UI和CLI把它们作为一个组来获取。对于IaaS本身,预先定义的业务逻辑也许从来都不能满足用户的需求。以创建虚拟机为例,默认的选择目标主机的算法是,从主机池中随机选择一个,但用户可能需要各种各样的算法来满足它们的使用情景。比如说选择内存超过8G的主机,选择拥有SR-IOV硬件的主机,或选择一个有当前用户的运行中虚拟机的主机。IaaS软件几乎不能为所有无止境的、不可预知的需求提供单独的API,必须有一种机制允许基础API(如APICreateVmInstanceMsg)携带额外信息。
根据各自的业务逻辑,插件可以选择是否创建数据库表。比如,Open vSwitch L2 Network插件,由于需要创建一种新的类型的资源,可能需要添加一张新表;然而,一个允许主机保留内存的插件可能不需要添加一张新表,而仅需在主机上附加一点数据。如果IaaS软件没有为插件提供一种附加数据,它们将开始创造新的、琐碎的模式或添加现有模式的列从而修改现有的模式,导致软件升级时数据库迁移的难处理的情况。
最后,对于建立在ZStack上的第三方软件,允许它们将信息存储到ZStack的数据库可以避免数据完整性问题,并使得它们可以使用ZStack的全部查询API(详见“查询API”)。
问题
大多数IaaS软件都有着标签的概念。然而,它们并不是都为不同场景定义了一个详尽的标签规范。例如,一些IaaS使用标签是为了用户聚合资源,一些IaaS是为了内部业务逻辑。ZStack则为不同场景的标签的每一个层面都精心设计了标签规范。
标签系统
在ZStack中,标签本质上是携带了少量资源相关信