1 Glance User Guide #

The term metadata can become very overloaded and confusing. This catalog is about the additional metadata that is passed as arbitrary key and value pairs or tags across various artifacts and OpenStack services.

Below are a few examples of the various terms used for metadata across OpenStack services today:

The below figure illustrates the concept terminology used in the metadata definitions catalog:

A namespace is associated with 0 to many resource types, making it visible to
the API and UI for applying to that type of resource. RBAC Permissions are
managed at a namespace level.

+----------------------------------------------+
|         Namespace                            |
|                                              |
| +-----------------------------------------+  |
| |        Object Definition                |  |
| |                                         |  |        +--------------------+
| | +-------------------------------------+ |  |  +-->  | Resource Type:     |
| | | Property Definition A (key=integer) | |  |  |     | e.g. Nova Flavor   |
| | +-------------------------------------+ |  |  |     +--------------------+
| |                                         |  |  |
| | +-------------------------------------+ |  |  |
| | | Property Definition B (key=string)  | |  |  |     +--------------------+
| | +-------------------------------------+ |  +--+-->  | Resource Type:     |
| |                                         |  |  |     | e.g. Glance Image  |
| +-----------------------------------------+  |  |     +--------------------+
|                                              |  |
|  +-------------------------------------+     |  |
|  | Property Definition C (key=boolean) |     |  |     +--------------------+
|  +-------------------------------------+     |  +-->  | Resource Type:     |
|                                              |        | e.g. Cinder Volume |
+----------------------------------------------+        +--------------------+

 Properties may be defined standalone or within the context of an object.

The following terminology is used within the metadata definition catalog.

Namespaces

Metadata definitions are contained in namespaces.

Properties

A property describes a single property and its primitive constraints. Each property can only be a primitive type:

Each primitive type is described using simple JSON schema notation. This means no nested objects and no definition referencing.

Objects

An object describes a group of one to many properties and their primitive constraints. Each property in the group can ONLY be a primitive type:

Each primitive type is described using simple JSON schema notation. This means no nested objects.

The object may optionally define required properties under the semantic understanding that a user who uses the object should provide all required properties.

Resource Type Association

Resource type association specifies the relationship between resource types and the namespaces that are applicable to them. This information can be used to drive UI and CLI views. For example, the same namespace of objects, properties, and tags may be used for images, snapshots, volumes, and flavors. Or a namespace may only apply to images.

Resource types should be aligned with Heat resource types whenever possible. http://docs.openstack.org/developer/heat/template_guide/openstack.html

It is important to note that the same base property key can require different prefixes depending on the target resource type. The API provides a way to retrieve the correct property based on the target resource type.

Below are a few examples:

The desired virtual CPU topology can be set on both images and flavors via metadata. The keys have different prefixes on images than on flavors. On flavors keys are prefixed with hw:, but on images the keys are prefixed with hw_.

For more: https://github.com/openstack/nova-specs/blob/master/specs/juno/implemented/virt-driver-vcpu-topology.rst.

Another example is the AggregateInstanceExtraSpecsFilter and scoped properties (For example, properties with something:something=value). For scoped or namespaced properties, the AggregateInstanceExtraSpecsFilter requires a prefix of aggregate_instance_extra_specs: to be used on flavors but not on the aggregate itself. Otherwise, the filter will not evaluate the property during scheduling.

So, on a host aggregate, you may see:

companyx:fastio=true

But then when used on the flavor, the AggregateInstanceExtraSpecsFilter needs:

aggregate_instance_extra_specs:companyx:fastio=true

In some cases, there may be multiple different filters that may use the same property with different prefixes. In this case, the correct prefix needs to be set based on which filter is enabled.

The v1 API was originally designed as a service API for use by Nova and other OpenStack services. In the Kilo release, the v1.1 API was downgraded from CURRENT to SUPPORTED. In the Newton release, the version 1 API is officially declared DEPRECATED.

During the deprecation period, the Images v1 API is closed to further development. The Glance code implementing the v1 API accepts only serious bug fixes.

Since Folsom, it has been possible to deploy OpenStack without exposing the Images v1 API to end users. The Compute v2 API contains image-related API calls allowing users to list images, list images details, show image details for a specific image, delete images, and manipulate image metadata. Nova acts as a proxy to Glance for these image-related calls. It’s important to note that the image-related calls in the Compute v2 API are a proper subset of the calls available in the Images APIs.

In the Newton release, Nova (and other OpenStack services that consume images) have been modified to use the Images v2 API by default.

Reference

The v2 API is the CURRENT OpenStack Images API. It provides a more friendly interface to consumers than did the v1 API, as it was specifically designed to expose images-related functionality as a public-facing endpoint. It’s the version that’s currently open to development.

A common strategy is to deploy multiple Glance nodes: internal-facing nodes providing the Images APIs for internal consumers like Nova, and external-facing nodes providing the Images v2 API for public use.

During the long and tumultuous design phase of what has since become an independent service named “Glare” (the Glance Artifacts Repository), the Glance community loosely spoke about the Artifacts API being “Glance v3”. This, however, was only a shorthand way of speaking of the Artifacts effort. The Artifacts API can’t be the Images v3 API since Artifacts are not the same as Images. Conceptually, a virtual machine image could be an Artifact, and the Glare code has been designed to be compatible with the Images v2 API. But at this time, there are no plans to implement an Images v3 API.

During the Newton development cycle, Glare became an independent OpenStack project. While it’s evident that there’s a need for an Artifact Repository in OpenStack, whether it will be as ubiquitous as the need for an Images Repository isn’t clear. On the other hand, industry trends could go in the opposite direction where everyone needs Artifacts and deployers view images as simply another type of digital artifact.

We want to see a list of available images that the authenticated user has access to. This includes images owned by the user, images shared with the user and public images.

We issue a GET request to http://glance.openstack.example.org/v1/images to retrieve this list of available images. The data is returned as a JSON-encoded mapping in the following format:

{'images': [
  {'uri': 'http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9',
   'name': 'SLES 15',
   'disk_format': 'vhd',
   'container_format': 'ovf',
   'size': '5368709120'}
  ...]}

We want to see a more detailed list of available images that the authenticated user has access to. This includes images owned by the user, images shared with the user and public images.

We issue a GET request to http://glance.openstack.example.org/v1/images/detail to retrieve this list of available images. The data is returned as a JSON-encoded mapping in the following format:

{'images': [
  {'uri': 'http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9',
   'name': 'SLES 15',
   'disk_format': 'vhd',
   'container_format': 'ovf',
   'size': '5368709120',
   'checksum': 'c2e5db72bd7fd153f53ede5da5a06de3',
   'created_at': '2010-02-03 09:34:01',
   'updated_at': '2010-02-03 09:34:01',
   'deleted_at': '',
   'status': 'active',
   'is_public': true,
   'min_ram': 256,
   'min_disk': 5,
   'owner': null,
   'properties': {'distro': 'SLES 15'}},
  ...]}

Note

All timestamps returned are in UTC.

The updated_at timestamp is the timestamp when an image’s metadata was last updated, not its image data, as all image data is immutable once stored in Glance.

The properties field is a mapping of free-form key and value pairs that have been saved with the image metadata.

The checksum field is an MD5 checksum of the image file data.

The is_public field is a boolean indicating whether the image is publicly available.

The min_ram field is an integer specifying the minimum amount of RAM needed to run this image on an instance in megabytes.

The min_disk field is an integer specifying the minimum amount of disk space needed to run this image on an instance in gigabytes.

The owner field is a string which may either be null or which will indicate the owner of the image.

Both the GET /v1/images and GET /v1/images/detail requests take query parameters that serve to filter the returned list of images. The following list details these query parameters.

These two resources also accept additional query parameters:

Note

If the specified LIMIT exceeds the operator defined limit (api_limit_max) then the number of results returned may be less than LIMIT.

Note

Use of the is_public parameter is restricted to admin users. For all other users it will be ignored.

We want to see detailed information for a specific virtual machine image that the Glance server knows about.

We have queried the Glance server for a list of images and the data returned includes the uri field for each available image. This uri field value contains the exact location needed to get the metadata for a specific image.

Continuing the example from above, in order to get metadata about the first image returned, we can issue a HEAD request to the Glance server for the image’s URI.

We issue a HEAD request to http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9 to retrieve complete metadata for that image. The metadata is returned as a set of HTTP headers that begin with the prefix x-image-meta-. The following shows an example of the HTTP headers returned from the above HEAD request:

x-image-meta-uri              http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9
x-image-meta-name             SLES 15
x-image-meta-disk_format      vhd
x-image-meta-container_format ovf
x-image-meta-size             5368709120
x-image-meta-checksum         c2e5db72bd7fd153f53ede5da5a06de3
x-image-meta-created_at       2010-02-03 09:34:01
x-image-meta-updated_at       2010-02-03 09:34:01
x-image-meta-deleted_at
x-image-meta-status           available
x-image-meta-is_public        true
x-image-meta-min_ram          256
x-image-meta-min_disk         0
x-image-meta-owner            null
x-image-meta-property-distro  SLES 15

Note

All timestamps returned are in UTC.

The x-image-meta-updated_at timestamp is the timestamp when an image’s metadata was last updated, not its image data, as all image data is immutable once stored in Glance.

There may be multiple headers that begin with the prefix x-image-meta-property-. These headers are free-form key and value pairs that have been saved with the image metadata. The key is the string after x-image-meta-property- and the value is the value of the header.

The response’s ETag header will always be equal to the x-image-meta-checksum value.

The response’s x-image-meta-is_public value is a boolean indicating whether the image is publicly available.

The response’s x-image-meta-owner value is a string which may either be null or which will indicate the owner of the image.

We want to retrieve that actual raw data for a specific virtual machine image that the Glance server knows about.

We have queried the Glance server for a list of images and the data returned includes the uri field for each available image. This uri field value contains the exact location needed to get the metadata for a specific image.

Continuing the example from above, in order to get metadata about the first image returned, we can issue a HEAD request to the Glance server for the image’s URI.

We issue a GET request to http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9 to retrieve metadata for that image as well as the image itself encoded into the response body.

The metadata is returned as a set of HTTP headers that begin with the prefix x-image-meta-. The following shows an example of the HTTP headers returned from the above GET request:

x-image-meta-uri              http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9
x-image-meta-name             SLES 15
x-image-meta-disk_format      vhd
x-image-meta-container_format ovf
x-image-meta-size             5368709120
x-image-meta-checksum         c2e5db72bd7fd153f53ede5da5a06de3
x-image-meta-created_at       2010-02-03 09:34:01
x-image-meta-updated_at       2010-02-03 09:34:01
x-image-meta-deleted_at
x-image-meta-status           available
x-image-meta-is_public        true
x-image-meta-min_ram          256
x-image-meta-min_disk         5
x-image-meta-owner            null
x-image-meta-property-distro  SLES 15

Note

All timestamps returned are in UTC.

The x-image-meta-updated_at timestamp is the timestamp when an image’s metadata was last updated, not its image data, as all image data is immutable once stored in Glance.

There may be multiple headers that begin with the prefix x-image-meta-property-. These headers are free-form key and value pairs that have been saved with the image metadata. The key is the string after x-image-meta-property- and the value is the value of the header.

The response’s Content-Length header shall be equal to the value of the x-image-meta-size header.

The response’s ETag header will always be equal to the x-image-meta-checksum value.

The response’s x-image-meta-is_public value is a boolean indicating whether the image is publicly available.

The response’s x-image-meta-owner value is a string which may either be null or which will indicate the owner of the image.

The image data itself will be the body of the HTTP response returned from the request, which will have content-type of application/octet-stream.

We have created a new virtual machine image in some way (created a snapshot or backed up an existing image) and we wish to do two things:

We can do the above two activities in a single call to the Glance API. Assuming, like in the examples above, that a Glance API server is running at http://glance.openstack.example.org, we issue a POST request to add an image to Glance:

POST http://glance.openstack.example.org/v1/images

The metadata about the image is sent to Glance in HTTP headers. The body of the HTTP request to the Glance API will be the MIME-encoded disk image data.

We can also perform the activities described in Section 1.9.3.6, “Add a New Image” using two separate calls to the Image API; the first to register the image metadata, and the second to add the image disk data. This is known as reserving an image.

The first call should be a POST to http://glance.openstack.example.org/v1/images, which will result in a new image id being registered with a status of queued:

{'image':
 {'status': 'queued',
  'id': '71c675ab-d94f-49cd-a114-e12490b328d9',
  ...}
 ...}

The image data can then be added using a PUT to http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9. The image status will then be set to active by Glance.

Image Metadata in HTTP Headers

Glance will view as image metadata any HTTP header that it receives in a POST request where the header key is prefixed with the strings x-image-meta- and x-image-meta-property-.

The list of metadata headers that Glance accepts are listed below.

Glance will consider any HTTP header that it receives in a PUT request as an instance of image metadata. In this case, the header key should be prefixed with the strings x-image-meta- and x-image-meta-property-.

If an image was previously reserved, and thus is in the queued state, then image data can be added by including it as the request body. If the image already has data associated with it (for example, it is not in the queued state), then including a request body will result in a 409 Conflict exception.

On success, the PUT request will return the image metadata encoded as HTTP headers.

See more about image statuses here Section 1.2, “Image Statuses”.

We want to see a list of the other system tenants (or users, if owner_is_tenant is False) that may access a given virtual machine image that the Glance server knows about. We take the uri field of the image data, append /members to it, and issue a GET request on the resulting URL.

Continuing from the example above, in order to get the memberships for the first image returned, we can issue a GET request to the Glance server for http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9/members. And we will get back JSON data such as the following:

{'members': [
 {'member_id': 'tenant1',
  'can_share': false}
 ...]}

The member_id field identifies a tenant with which the image is shared. If that tenant is authorized to further share the image, the can_share field is true.

We want to see a list of images which are shared with a given tenant. We issue a GET request to http://glance.openstack.example.org/v1/shared-images/tenant1. We will get back JSON data such as the following:

{'shared_images': [
 {'image_id': '71c675ab-d94f-49cd-a114-e12490b328d9',
  'can_share': false}
 ...]}

The image_id field identifies an image shared with the tenant named by member_id. If the tenant is authorized to further share the image, the can_share field is true.

We want to authorize a tenant to access a private image. We issue a PUT request to http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9/members/tenant1. With no body, this will add the membership to the image, leaving existing memberships unmodified and defaulting new memberships to have can_share set to false. We may also optionally attach a body of the following form:

{'member':
 {'can_share': true}
}

If such a body is provided, both existing and new memberships will have can_share set to the provided value (either true or false). This query will return a 204 (No Content) status code.

We want to revoke a tenant’s right to access a private image. We issue a DELETE request to http://glance.openstack.example.org/v1/images/1/members/tenant1. This query will return a 204 (No Content) status code.

The full membership list for a given image may be replaced. We issue a PUT request to http://glance.openstack.example.org/v1/images/71c675ab-d94f-49cd-a114-e12490b328d9/members with a body of the following form:

{'memberships': [
 {'member_id': 'tenant1',
  'can_share': false}
 ...]}

All existing memberships which are not named in the replacement body are removed, and those which are named have their can_share settings changed as specified. (The can_share setting may be omitted, which will cause that setting to remain unchanged in the existing memberships.) All new memberships will be created, with can_share defaulting to false unless it is specified otherwise.

A user wants to initiate a Task. The user issues a POST request to /v2/tasks. The request body is of Content-type application/json and must contain the following fields:

The response is a Task entity as defined by the Task schema. It includes an id field that can be used in a subsequent call to poll the Task for status changes.

A Task is created in pending status.

A user wants to see detailed information about a Task the user owns. The user issues a GET request to /v2/tasks/{taskId}.

The response is in application/json format. The exact structure is given by the Task schema located at /v2/schemas/task.

A user wants to see what Tasks have been created in their project. The user issues a GET request to /v2/tasks.

The response is in application/json format. The exact structure is given by the task schema located at /v2/schemas/tasks.

Note

As indicated by the schema, the list of Tasks is provided in a sparse format. To see more information about a particular Task in the list, the user would use the show Task call described above.

The GET /v2/tasks request takes query parameters that server to filter the returned list of Tasks. The following list details these query parameters.

To receive localized API messages, the HTTP client needs to specify the Accept-Language header to indicate the language that will translate the message. For more information about Accept-Language, refer to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

A typical curl API request will be like below:

curl -i -X GET -H 'Accept-Language: zh' -H 'Content-Type: application/json'
http://glance.openstack.example.org/v2/images/aaa

Then the response will be like the following:

HTTP/1.1 404 Not Found
Content-Length: 234
Content-Type: text/html; charset=UTF-8
X-Openstack-Request-Id: req-54d403a0-064e-4544-8faf-4aeef086f45a
Date: Sat, 22 Feb 2014 06:26:26 GMT

<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>404 Not Found</h1>
&#25214;&#19981;&#21040;&#20219;&#20309;&#20855;&#26377;&#26631;&#35782; aaa &#30340;&#26144;&#20687;<br /><br />
</body>
</html>

Note

Make sure to have a language package under /usr/share/locale-langpack/ on the target Glance server.

We want to see a list of available namespaces that the authenticated user has access to. This includes namespaces owned by the user, namespaces shared with the user and public namespaces.

We issue a GET request to http://glance.openstack.example.org/v2/metadefs/namespaces to retrieve this list of available namespaces. The data is returned as a JSON-encoded mapping in the following format:

{
  "namespaces": [
      {
          "namespace": "MyNamespace",
          "display_name": "My User Friendly Namespace",
          "description": "My description",
          "visibility": "public",
          "protected": true,
          "owner": "The Test Owner",
          "self": "/v2/metadefs/namespaces/MyNamespace",
          "schema": "/v2/schemas/metadefs/namespace",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z",
          "resource_type_associations": [
              {
                  "name": "OS::Nova::Aggregate",
                  "created_at": "2014-08-28T17:13:06Z",
                  "updated_at": "2014-08-28T17:13:06Z"
              },
              {
                  "name": "OS::Nova::Flavor",
                  "prefix": "aggregate_instance_extra_specs:",
                  "created_at": "2014-08-28T17:13:06Z",
                  "updated_at": "2014-08-28T17:13:06Z"
              }
          ]
      }
  ],
  "first": "/v2/metadefs/namespaces?sort_key=created_at&sort_dir=asc",
  "schema": "/v2/schemas/metadefs/namespaces"
}

Note

Listing namespaces will only show the summary of each namespace including counts and resource type associations. Detailed responses including all its objects definitions, property definitions will only be available on each individual GET namespace request.

GET /v2/metadefs/namespaces requests take query parameters that serve to filter the returned list of namespaces. The following list details these query parameters.

GET resource also accepts additional query parameters:

Note

If the specified LIMIT exceeds the operator defined limit (api_limit_max) then the number of results returned may be less than LIMIT.

We want to see a more detailed information about a namespace that the authenticated user has access to. The detail includes the properties, objects, and resource type associations.

We issue a GET request to http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace} to retrieve the namespace details. The data is returned as a JSON-encoded mapping in the following format:

{
  "namespace": "MyNamespace",
  "display_name": "My User Friendly Namespace",
  "description": "My description",
  "visibility": "public",
  "protected": true,
  "owner": "The Test Owner",
  "schema": "/v2/schemas/metadefs/namespace",
  "resource_type_associations": [
      {
          "name": "OS::Glance::Image",
          "prefix": "hw_",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z"
      },
      {
          "name": "OS::Cinder::Volume",
          "prefix": "hw_",
          "properties_target": "image",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z"
      },
      {
          "name": "OS::Nova::Flavor",
          "prefix": "filter1:",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z"
      }
  ],
  "properties": {
      "nsprop1": {
          "title": "My namespace property1",
          "description": "More info here",
          "type": "boolean",
          "default": true
      },
      "nsprop2": {
          "title": "My namespace property2",
          "description": "More info here",
          "type": "string",
          "default": "value1"
      }
  },
  "objects": [
      {
          "name": "object1",
          "description": "my-description",
          "self": "/v2/metadefs/namespaces/MyNamespace/objects/object1",
          "schema": "/v2/schemas/metadefs/object",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z",
          "required": [],
          "properties": {
              "prop1": {
                  "title": "My object1 property1",
                  "description": "More info here",
                  "type": "array",
                  "items": {
                      "type": "string"
                  }
              }
          }
      },
      {
          "name": "object2",
          "description": "my-description",
          "self": "/v2/metadefs/namespaces/MyNamespace/objects/object2",
          "schema": "/v2/schemas/metadefs/object",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z",
          "properties": {
              "prop1": {
                  "title": "My object2 property1",
                  "description": "More info here",
                  "type": "integer",
                  "default": 20
              }
          }
      }
  ]
}

We want to see the list of all resource types that are available in Glance.

We issue a GET request to http://glance.openstack.example.org/v2/metadefs/resource_types to retrieve all resource types.

The data is returned as a JSON-encoded mapping in the following format:

{
  "resource_types": [
      {
          "created_at": "2014-08-28T17:13:04Z",
          "name": "OS::Glance::Image",
          "updated_at": "2014-08-28T17:13:04Z"
      },
      {
          "created_at": "2014-08-28T17:13:04Z",
          "name": "OS::Cinder::Volume",
          "updated_at": "2014-08-28T17:13:04Z"
      },
      {
          "created_at": "2014-08-28T17:13:04Z",
          "name": "OS::Nova::Flavor",
          "updated_at": "2014-08-28T17:13:04Z"
      },
      {
          "created_at": "2014-08-28T17:13:04Z",
          "name": "OS::Nova::Aggregate",
          "updated_at": "2014-08-28T17:13:04Z"
      },
      {
          "created_at": "2014-08-28T17:13:04Z",
          "name": "OS::Nova::Server",
          "updated_at": "2014-08-28T17:13:04Z"
      }
  ]
}

We want to see the list of resource types that are associated for a specific namespace.

We issue a GET request to http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/resource_types to retrieve resource types.

The data is returned as a JSON-encoded mapping in the following format:

{
  "resource_type_associations" : [
      {
         "name" : "OS::Glance::Image",
         "prefix" : "hw_",
         "created_at": "2014-08-28T17:13:04Z",
         "updated_at": "2014-08-28T17:13:04Z"
      },
      {
         "name" :"OS::Cinder::Volume",
         "prefix" : "hw_",
         "properties_target" : "image",
         "created_at": "2014-08-28T17:13:04Z",
         "updated_at": "2014-08-28T17:13:04Z"
      },
      {
         "name" : "OS::Nova::Flavor",
         "prefix" : "hw:",
         "created_at": "2014-08-28T17:13:04Z",
         "updated_at": "2014-08-28T17:13:04Z"
      }
  ]
}

We want to create a new namespace that can contain the properties, objects, etc.

We issue a POST request to add an namespace to Glance:

POST http://glance.openstack.example.org/v2/metadefs/namespaces/

The input data is an JSON-encoded mapping in the following format:

{
  "namespace": "MyNamespace",
  "display_name": "My User Friendly Namespace",
  "description": "My description",
  "visibility": "public",
  "protected": true
}

Note

Optionally properties, objects and resource type associations could be added in the same input. See GET Namespace output above (input will be similar).

We want to update an existing namespace.

We issue a PUT request to update an namespace to Glance:

PUT http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}

The input data is similar to Add Namespace.

We want to delete an existing namespace including all its objects, properties etc.

We issue a DELETE request to delete an namespace to Glance:

DELETE http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}

We want to associate a resource type with an existing namespace.

We issue a POST request to associate resource type to Glance:

POST http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/resource_types

The input data is an JSON-encoded mapping in the following format:

{
        "name" :"OS::Cinder::Volume",
        "prefix" : "hw_",
        "properties_target" : "image",
        "created_at": "2014-08-28T17:13:04Z",
        "updated_at": "2014-08-28T17:13:04Z"
}

We want to de-associate namespace from a resource type.

We issue a DELETE request to de-associate namespace resource type to Glance:

DELETE http://glance.openstack.example.org/v2//metadefs/namespaces/{namespace}/resource_types/{resource_type}

We want to see the list of meta definition objects in a specific namespace.

We issue a GET request to http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/objects to retrieve objects.

The data is returned as a JSON-encoded mapping in the following format:

{
      "objects": [
      {
          "name": "object1",
          "description": "my-description",
          "self": "/v2/metadefs/namespaces/MyNamespace/objects/object1",
          "schema": "/v2/schemas/metadefs/object",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z",
          "required": [],
          "properties": {
              "prop1": {
                  "title": "My object1 property1",
                  "description": "More info here",
                  "type": "array",
                  "items": {
                      "type": "string"
                  }
              }
          }
      },
      {
          "name": "object2",
          "description": "my-description",
          "self": "/v2/metadefs/namespaces/MyNamespace/objects/object2",
          "schema": "/v2/schemas/metadefs/object",
          "created_at": "2014-08-28T17:13:06Z",
          "updated_at": "2014-08-28T17:13:06Z",
          "properties": {
              "prop1": {
                  "title": "My object2 property1",
                  "description": "More info here",
                  "type": "integer",
                  "default": 20
              }
          }
      }
  ],
  "schema": "/v2/schemas/metadefs/objects"
}

We want to create a new object which can group the properties.

We issue a POST request to add object to a namespace in Glance:

POST http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/objects

The input data is an JSON-encoded mapping in the following format:

{
  "name": "StorageQOS",
  "description": "Our available storage QOS.",
  "required": [
      "minIOPS"
  ],
  "properties": {
      "minIOPS": {
          "type": "integer",
          "description": "The minimum IOPs required",
          "default": 100,
          "minimum": 100,
          "maximum": 30000369
      },
      "burstIOPS": {
          "type": "integer",
          "description": "The expected burst IOPs",
          "default": 1000,
          "minimum": 100,
          "maximum": 30000377
      }
  }
}

We want to update an existing object.

We issue a PUT request to update an object to Glance:

PUT http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/objects/{object_name}

The input data is similar to Add Object.

We want to delete an existing object.

We issue a DELETE request to delete object in a namespace to Glance:

DELETE http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/objects/{object_name}

We want to create a new property definition in a namespace.

We issue a POST request to add property definition to a namespace in Glance:

POST http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/properties

The input data is an JSON-encoded mapping in the following format:

{
  "name": "hypervisor_type",
  "title" : "Hypervisor",
  "type": "array",
  "description": "The type of hypervisor required",
  "items": {
      "type": "string",
      "enum": [
          "hyperv",
          "qemu",
          "kvm"
      ]
  }
}

We want to update an existing object.

We issue a PUT request to update an property definition in a namespace to Glance:

PUT http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/properties/{property_name}

The input data is similar to Add property definition.

We want to delete an existing object.

We issue a DELETE request to delete property definition in a namespace to Glance:

DELETE http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}/properties/{property_name}

To receive localized API messages, the HTTP client needs to specify the Accept-Language header to indicate the language to use to translate the message. For more info about Accept-Language, refer http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

A typical curl API request will be like below:

curl -i -X GET -H 'Accept-Language: zh' -H 'Content-Type: application/json'
http://glance.openstack.example.org/v2/metadefs/namespaces/{namespace}

Then the response will be like the following:

HTTP/1.1 404 Not Found
Content-Length: 234
Content-Type: text/html; charset=UTF-8
X-Openstack-Request-Id: req-54d403a0-064e-4544-8faf-4aeef086f45a
Date: Sat, 22 Feb 2014 06:26:26 GMT

<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>404 Not Found</h1>
&#25214;&#19981;&#21040;&#20219;&#20309;&#20855;&#26377;&#26631;&#35782; aaa &#30340;&#26144;&#20687;<br /><br />
</body>
</html>

Note

Ensure there is the language package under /usr/share/locale-langpack/ on the target Glance server.

This is the signature of your image.

Note

The max character limit is 255.

Hash methods is the method you hash with.

Current ones you can use are:

This is the key_types you can use for your image.

Current ones you can use are:

Note

ECC curves - Only keysizes above 384 are included. Not all ECC curves may be supported by the back end.

This is the UUID of the certificate that you upload to Barbican.

Therefore the type passed to glance is:

Note

The supported certificate types are:

• X_509