OpenStack Glance(s) at Artifacts
In this article, we take a look at the powerful potential of Artifacts to enhance OpenStack's image service project, Glance. Introduced in 2011 as the third component in OpenStack, following Nova and Swift, Glance improved the upload and discovery capabilities of these services’ data assets, enabling more flexible interaction. Artifacts would extend Glance’s current services to newer OpenStack projects by supporting storage for various binary objects and VM images. It is proposed for the Kilo release.
Artifacts is a modular system, where artifact means a block of binary data stored with its descriptive metadata. Each artifact has a type, which defines the storage structure of its binary data and metadata, actions that can be applied to an artifact, and an artifact's dependencies.
Figure 1: Glance with Artifacts architecture
VM images are one example of artifacts, but artifacts could also be Murano Application Packages, Mistral Workbooks, Heat templates or Solum Plan Files (Figure 1). Each type of artifact corresponds to its own plug-in (module), which defines the artifact's custom metadata fields, BLOB kinds, importing logic, and so on.
The plan is for relevant modules to be easily appended to Glance as soon as new projects are created. Basic modules will initially be offered to existing services such as Heat, Mistral, Murano, etc. Nova images will also be treated as an artifact type, but for the time being the existing "hardcoded" imaging functionality remains independent from the artifacts.
Glance will provide the following functionality to all artifact types:
Guarantee artifact immutability once it is stored
Provide search capabilities to find the artifacts in a catalog
Return detailed information about the requested artifact
Allow artifact retrieval for usage by a service
Control access to an artifact by enforcing usage and modification policies, sharing and publication processes, etc.
Manage the artifact life-cycle.
Users will work with artifacts through a unified interface similar to the one used for Nova images. Each installed module will have a name correspondent with the REST API. For example, a Murano application catalog (apps) could be /v2/artifacts/apps.
Next Steps
As development continues, Glance should provide connections with various storage systems such as Swift, Ceph, S3 and Sheepdog, ensuring convenient interaction with high level OpenStack projects.
In addition, Glance should be able to store different versions of the same artifact. From storage's point of view, different versions of one artifact are independent objects that have the same type and name but differ in the value of the “version” field. However, from the upper level versions should appear as one monolithic artifact, and the user can easily switch between its versions. Artifact types should also have versions to comply with the dynamic nature of OpenStack development. Glance must be able to work with the entire line of versions to maintain compatibility.
Artifacts’ dependency relations also need to be considered because an artifact may depend on any number of other artifacts of any type and version. The dependency relations are useful as the entities in OpenStack ecosystems rarely operate alone and usually interact with each other. In practice, an artifact may frequently need to work with other artifacts in some way, so introducing dependencies is the best solution when building a hierarchy of artifacts.
The introduction of artifacts to Glance is a great leap forward. Let's cross our fingers that soon Glance will be known as the Artifact Service!
