• StructuredMetadata

• Launchpad Entry: foo or foo

• Created:

• Contributors:

Summary

support structure data in glance metadata The the moment glance metadata is simple key value pair. Thus structured data (list and dict)

Release Note

No visible change for end user. This feature is necessary for boot-from-volume feature. Main change will be at glance API. So Glance client might see the change.

Rationale

Why structure data is wanted?

For boot-from-volume support in nova, the information about block device mapping is stored in image metadata which is stored as metadata of glance. That is, which device of guest device is which nova volume/ephemeral devices. So it's a list of dict.

Example of metadata

metadata = {'name': 'fake public image',
           'properties': {
               'mappings': [
                   {'device_name': '/dev/sda1',
                    'snapshot_id': 0x12345678,
                    'delete_on_termination': False},
                   {'device_name': '/dev/sda2',
                    'no_device': True}],
               'block_device_mapping':  [
                        {'virtual': 'ami', 'device': 'sda1'},
                        {'virtual': 'root', 'device': '/dev/sda1'},

                        {'virtual': 'swap', 'device': 'sdb1'},
                        {'virtual': 'swap', 'device': 'sdb2'},

                        {'virtual': 'ephemeral0', 'device': 'sdc1'},
                        {'virtual': 'ephemeral1', 'device': 'sdc2'}]}}

User stories

Assumptions

Design

There are several candidates for possible implementations.

* Glance don't know about its value. client should do serialization/deserialization When glance client wants store, client have to convert into text blob by json.dumps

• Pros
  • simple, no changes to glance
• Cons
  • client needs to be aware of data structure.
  • precludes glance filter ability

* Glance does serialization/desrialization

• Pros
  • simple, no changes to client
• Cons
  • glance needs to be aware of data structure.
  • precludes glance filter ability

* Glance understands structured

• Pros
  • allows glance filter ability
• Cons
  • complex to implement (the poc patch is already available)

* implement as Glance extension for additional metadata The mapping should be implemented as new middleware on the register or even as an extention.

  PUT /images/<ID>/container-format

  with a body of something like:

  'format': {
    'mappings': [
                   {'device_name': '/dev/sda1',
                    'snapshot_id': 0x12345678,
                    'delete_on_termination': False},
                   {'device_name': '/dev/sda2',
                    'no_device': True}
    ],
    'block_device_mapping': [
                   {'virtual': 'ami', 'device': 'sda1'},
                   {'virtual': 'root', 'device': '/dev/sda1'},
                   {'virtual': 'swap', 'device': 'sdb1'},
                   {'virtual': 'swap', 'device': 'sdb2'},
                   {'virtual': 'ephemeral0', 'device': 'sdc1'},
                   {'virtual': 'ephemeral1', 'device': 'sdc2'}
    ],
  }

• And then, the extension/middleware can store specific information about the container in separate tables in the database that can be queried using a more specific API than the very limited custom key/value properties we currently have.
• Pros
  • allows glance filter ability
  • don't affect the existing code
  • clean implementation
  • would be future extensible.
    • When we'd like to add other structured metadata in the future, it would be easy as this is the model case.
• Cons
  • more effort to implement

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec