Jump to: navigation, search

Difference between revisions of "Murano/Generic Metadata Repository"

Line 1: Line 1:
=Generic Metadata Repository (proposal)=
+
==Generic Metadata Repository (proposal)==
  
==Introduction==
+
===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.
 
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.
Line 8: Line 8:
 
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.
 
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==
+
===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.  
 
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 it can be applied to other use-cases requiring to store objects with some associated metadata. The most common and best-known service implementing this approach is [[Glance | 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
 
This description is quite generic, and obviously it can be applied to other use-cases requiring to store objects with some associated metadata. The most common and best-known service implementing this approach is [[Glance | 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

Revision as of 10:58, 13 December 2013

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 it can be applied to other use-cases requiring to store objects with some associated metadata. The most common and best-known service implementing this approach 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