Clarify the format of the Flavor content stored in the database

This clarifies some verbiage in the flavor-from-sysmeta-to-blob
spec, which didn't make it in before the spec was approved.

Change-Id: I423d6741720cf9d04f7c2c9030bb49386e05c5b4
This commit is contained in:
Dan Smith
2014-10-14 07:28:28 -07:00
parent d8c3b33231
commit f5212b6ed0

View File

@@ -79,11 +79,16 @@ we will store a JSONified copy of the flavor on initial boot. Further,
we will provide for storage of an 'old' and 'new' flavor to facilitate
resize operations. The top-level structure will look like this::
{'cur': {'flavorid': 'foo', 'memory_mb': 1024, ...},
{'cur': { ... serialized Flavor object ... }
'new': None,
'old': None,
}
When a flavor is stored in one of the three slots above, the form used
will be the serialized NovaObject result. This means that the content
in the database will be versioned and deserializing it from the
database will work just like receiving one over RPC.
The database migration for this change will simply add the new column,
but not perform a data migration. Instead, the migration from
system_metadata to instance_extra will be managed by the objects