StructuredMetadata - Revision history

Ryan Lane: Text replace - "SwiftSpec" to "SwiftSpec"

2013-02-17T23:31:47Z

Text replace - "SwiftSpec" to "SwiftSpec"

Ryan Lane: Text replace - "NovaSpec" to "NovaSpec"

2013-02-17T23:31:10Z

Text replace - "NovaSpec" to "NovaSpec"

Ryan Lane: Text replace - "NOTOC" to ""

2013-02-17T23:30:48Z

Text replace - "__NOTOC__" to ""

IsakuYamahata at 05:31, 1 July 2011

2011-07-01T05:31:46Z

IsakuYamahata at 05:21, 1 July 2011

2011-07-01T05:21:06Z

New page

__NOTOC__
* '''Launchpad Entry''': [[NovaSpec]]:foo or [[SwiftSpec]]: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

<pre><nowiki>
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'}]}}
</nowiki></pre>

== 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.

<pre><nowiki>
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'}
],
}
</nowiki></pre>

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
** 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.

----
[[Category:Spec]]

@@ Line 1: / Line 1: @@
-* '''Launchpad Entry''': NovaSpec:foo or [[SwiftSpec]]:foo
+* '''Launchpad Entry''': NovaSpec:foo or SwiftSpec:foo
 * '''Created''':
 * '''Contributors''':