Murano/Generic Metadata Repository
Contents
Generic Metadata Repository (proposal)
Introduction
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.
Mission generalisation
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.
Glance
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.
HeatR
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.
HOT
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
