Tags in ZStack not only help users aggregate resources, but also help control software behavior. ZStack has a complete set of specifications that define tag categories, forms, and usage. In addition to users, plug-ins can create their own tags to record metadata and extend existing resource attributes; By these means, tags can help plug-ins introduce new features without changing ZStack’s database structure, eliminating the need for database migration during software upgrades.

motivation

As resources continue to grow in the cloud, users may want a way to group similar resources using human-readable tags. For example, all virtual machines on Web servers can have a label ‘web-tier-VM’, which can be retrieved from the UI and CLI as a group. For IaaS itself, predefined business logic may never meet user requirements. For example, to create a VM, the default algorithm for selecting a target host is to randomly select one from the host pool, but users may need a variety of algorithms to suit their usage scenarios. For example, select a host with more than 8 GB of memory, select a host with SR-IOV hardware, or select a host with a running VIRTUAL machine of the current user. IaaS software can hardly provide a single API for all the endless and unpredictable requirements, and there must be a mechanism that allows the underlying API (such as APICreateVmInstanceMsg) to carry additional information.

Depending on their business logic, plug-ins can choose whether or not to create database tables. For example, the Open vSwitch L2 Network plug-in may need to add a new table because it needs to create a new type of resource; However, a plug-in that allows the host to retain memory might not need to add a new table, but simply attach a bit of data to the host. If IaaS software does not provide an additional piece of data for plug-ins, they will start creating new, trivial schemas or modifying existing schemas by adding columns for existing schemas, leading to unmanageable database migration situations when software is upgraded. Finally, for third-party software built on top of ZStack, allowing them to store information in ZStack’s database avoids data integrity issues and makes available ZStack’s full query API (see “Query API”).

The problem

Most IaaS software has the concept of a tag. However, they do not all define an exhaustive tag specification for different scenarios. For example, some IaaS use tags for user aggregation of resources, and some IaaS use tags for internal business logic. ZStack has carefully designed label specifications for each layer of labels in different scenarios.

Tagging system

In ZStack, labels are essentially strings that carry a small amount of resource-related information. A label usually consists of the following fields:

The essential difference between ZStack and other IaaS software in terms of tags is that ZStack divides tags into two categories: users and systems.

1. User labels

User tags, as the name suggests, are tags created by users for grouping resources. For example, use the tag ‘apache2-http’ to group VMS with apache2 HTTP server installed so that users can obtain these VMS through the query API, using the tag ‘apache2-http’ as query criteria:

QueryVmInstance __userTag__=apache2-http`
Copy the code

Note: See “Query API” for details.

This is the most common way of using tags. A resource can be associated with multiple tags and divided into different logical groups.

User tags can also be used in conjunction with system tags to control ZStack behavior. For example, if a user-labeled SSD is already created on the primary storage system, a system label can instruct ZStack to create the VM root directory on the primary storage with the user-labeled SSD. In this case, the user tag is more like the resource metadata entered by the user. As we’ll see shortly, plug-ins can also create resource metadata using system tags.

2. System labels

Unlike user tags, which can be created by the user at any time with any value, system tags have a fixed format and are predefined by ZStack’s business services and plug-ins and can be used in the following scenarios:

2.1 the metadata

Plug-ins can use system tags to record metadata for resources. For example, the host database table does not record metadata such as hypervisor version and Hypervisor SDK version. However, derived host plug-ins, such as KVM host plug-ins, may require this metadata to determine whether the current virtual machine hypervisor has certain characteristics; For example, whether you can take an online snapshot of the KVM depends on the libvirt and QEMU versions. In the ZStack, the KVM host plug-in saves the OS version, libvirt version, QEMU version, and qEMU-IMG tool version as system tags when connecting to a back-end host.

QuerySystemTag fields=tag resourceUuid=d07066c4de02404a948772e131139eb4 { "inventories": [ { "tag": "Capability: liveSnapshot"}, {" tag ":" qemu - img: : version: : 2.0.0 "}, {" tag ":" OS: : version: : 14.04 "}, {" tag ": "Libvirt: : version: : 1.2.2"}, {" tag ":" OS: : release: : trusty "}, {" tag ":" OS: : distribution: : Ubuntu} ", "success" : true }Copy the code

2.2 Resource Attributes

Plug-ins can also add new properties to resources using system tags. For example, there is no column in the database mode of the virtual machine to record which IP assignment algorithm should be used and when the virtual machine network card should be assigned. This additional attribute can be implemented using system tags. There is no limit to the number of system tags that plug-ins can create, and additional plug-ins can take advantage of this without interfering with the database schema.

Database tables and system labels: Because both database tables and system labels can define resource attributes, it can sometimes be difficult to decide whether the attributes should be a column in a database schema or a system label in a separate table. Adding new columns to modify an existing database schema usually requires database migration, which is a major pain point for IaaS software upgrades. So developers may prefer to use system tags to represent new attributes. However, abusing system tags is the wrong way to program. According to the convention of ZStack, only system tags should be used to introduce non-native resource attributes; System tags will not save poorly designed database tables. For example, if a VM’s database table is missing the cluster UUID (though it is not), it must be replaced even if a database migration is required; But a department ID introduced by a user-created plug-in for private use should be implemented as a system tag. This trade-off is not always easy, and we strictly control any changes to the database structure.

2.3 yuan programming

System tags can also annotate resources to influence the execution flow of ZStack, which is somewhat similar to Metaprogramming. For example, an administrator can create a system label on a KVM host that prompts the ZStack host allocator to reserve 1 gb of memory from the host’s available memory. If the administrator changes his mind, he can reclaim the gigabyte by removing the tag. There are many similar system tags.

For example, in the user tag section, we mentioned using both user tag SSDS and system tags to specify primary storage for the root cloud disk of the VM. System TAB called primaryStorage: : allocator: : userTag: : {tag} : : required, if on a virtual machine instance specification primaryStorage: : allocator: : userTag: : SSD: : required, The tasks of the VM root cloud disk created from the VM instance specifications will be allocated to the primary storage that has the user label SSD. There are many code called interpretive points that look for specific system tags during execution and can change the code’s default behavior.

2.4 Third-party Software Integration

Third-party software built on ZStack can use system labels to store information associated with resources in the ZStack database, which can effectively avoid data inconsistency between third-party software database and ZStack database.

For example, a proprietary software might need to record the department IDS of a virtual machine to audit the use of IT resources in each department, a function that is usually performed by a proprietary database and forces the proprietary software to track the life cycle of the virtual machine because IT needs to update its own database as IT is created or destroyed. Otherwise, the data will not accurately reflect the real situation.

With the help of system tags, proprietary software can use system tags such as Audit ::departmentId::{ID} to store information in ZStack’s database, transferring responsibility for managing the life cycle of department IDS to ZStack. When a virtual machine is destroyed, its departmentId (for example audit::departmentId::1) is automatically deleted in the database transaction that deletes the records for the virtual machine. In addition, proprietary software can retrieve virtual machines using their department IDS by calling the regular query API:

QueryVmInstance fields=uuid __sysTag__=audit::departmentId::1
Copy the code

Note: In ZStack version (0.6), we have not yet opened the interface to allow arbitrary system tags to be defined; all system tags are predefined. We plan to open this interface in the next release, and user-defined system tags can be created with some system-allowed prefixes, such as 3rd::.

Relationships with other components

Label system is one of the core components of ZStack. It not only has separate apis and services, but also integrates seamlessly with other core components. Users can create labels when or after a resource is created. All of ZStack’s creative apis support two built-in parameters: userTags and systemTags, through which the tags passed will be created with the resource. Such as:

CreateVmInstance name=testTag systemTags=hostname::web-server-1 l3NetworkUuids=6572ce44c3f6422d8063b0fb262cbc62
instanceOfferingUuid=04b5419ca3134885be90a48e372d3895 imageUuid=f1205825ec405cd3f2d259730d47d1d8
Copy the code

If the resource already exists, the user can use the tag API to create or remove tags:

CreateUserTag resourceType=VmInstanceVO resourceUuid=613af3fe005914c1643a15c36fd578c6 tag=web
DeleteTag uuid=596070a6276746edbf0f54ef721f654e
Copy the code

When a resource is deleted, the label associated with the resource is automatically deleted. Resources can be queried using two special query criteria: the __userTag__and__systemTag__ tag:

QueryVmInstance __userTag__=web zoneUuid=04b5419ca3134885be90a48e372d3895
QueryHost __systemTag__=capability:liveSnapshot
Copy the code

There are also query apis dedicated to categorizing:

QueryUserTag resourceUuid=0cd1ef8c9b9e0ba82e0cc9cc17226a26 tag~=web-server-%
QuerySystemTag resourceUuid=50fcc61947f7494db69436ebbbefda34
Copy the code

# summary

In this article, we show ZStack’s tagging system. Through this system, users, plug-ins, and third-party software can use tags in a variety of ways without changing the code and database table structure. This is another fundamental point that inspires the potential for ZStack to rapidly evolve into a mature, complete cloud computing solution while keeping its core architecture strong and stable.