Murano/Generic Metadata Repository
- 1 Generic Metadata Repository (proposal)
- 1.1 Introduction
- 1.2 Mission generalisation
- 1.3 Murano Requirements
- 1.4 Other Use-Cases
- 1.5 Glance
Generic Metadata Repository (proposal)
Murano Application Catalog works with Cloud Applications and Services. These may have diverse inner structures and some sophisticated deployment and maintenance logic, and Murano requires to have complete definitions of these logic and structure. Also, the applications themselves often require some external dependencies or binaries which have to be bundled with the Applications to install and operate properly. In Murano Catalog these definitions and dependencies are grouped into the collections, which are then archived to single binary files (tar-gzip in their format, but having different extension), called Murano Repository Packages. As the catalog grows up, storing and manipulating these Packages becomes a complicated task, which is quite independent from the rest of Murano's functionality.
That is why it was suggested to create a new service - Generic Metadata Repository - which will provide the required functionality to manipulate these packages, store them index and catalog properly - all without knowing anything about their inner structure or any other specifics related to Murano Catalog.
As described above Metadata Repository does not have any knowledge of the inner structure of Murano Repository Packages. So, from its point of view, these packages are simple binary objects, which need to be stored with some associated metadata values, indexed by these values and then listed and retrieved, with optional filtering by the metadata value. Another obvious requirement is immutability: once the object is uploaded into the repository, it gets a unique identifier assigned to it, and no further modifications of the object may occur: if the object has to be modified, a new version has to be uploaded to the repository, and the new ID will be assigned to this newer revision. Meanwhile, the metadata values , which are associated to the objects (or at least some of them), may be changed without changing the ID.
This description is quite generic, and obviously can be applied to other use-cases requiring to store objects with some associated metadata. So, Murano Application catalog is not the only service which will make use of having Metadata Repository: Openstack ecosystem has got a lot of projects which may benefit from it.
There is no need to implement this proposal as a standalone project, neither should it be part of Murano Application Catalog. It turns out (at least there was a consensus on that in the mailing list thread) that the most suitable project for this functionality is Glance program, as the described use-cases matches the best with ones of Glance. The actual implementation may vary: this functionality may be added directly to Glance at some point, or become a separate project under the Glance program. The purpose of this document is not to suggest any ways of implementations, but rather to gather various requirements and use-cases and have the complete (more or less) feature set, which may be used as a base point for submitting blueprints.
This section defines generic requirements which Murano has for the generic metadata repository.
Uploading a package
Download a package
Get the inheritance hierarchy
The most common and best-known service implementing this approach already exists and is widely adopted: it is Openstack Image Service ("Glance"). It manipulates with virtual machine images and their metadata, providing services to register, upload, query, discover and retrieve the images. Similar to what is described above, Glance does not actually process the contents of the Images - it just stores and manipulates them as simple binary files, without looking inside. The immutability rule is also one of the key requirement for Glance: once the image is uploaded it has a permanent id assigned, and cannot be modified.
Another example of OpenStack initiative requiring the same Metadata Repository functionality is a Heat Template Repository proposal: Heat project requires a service for the storage, management, and versioning of "known good" templates - and most of the requirements for this service fit well to the above described generic repository.
Another initiative of Heat project - HOT Software orchestration may also requre a storage for Software configurations. HOT specification assumes that scripts and resipes are accesible via URL specified in HOT Software orchestration resource. Metadata repository can be used as a central storage for HOT software components assets. The benefits for HOT are the following:
- Metadata repository is a part of OpenStack and will be always available for usage
- Metadata repository will have a UI part in OpenStack horizon, so user will have a way to manage software component assets
There may be other projects requiring similar storage functionality. This list may be expanded to gather the requirements and use-cases from other programs, projects and initiatives in OpenStack community.