Migration the data from core into an extension is not
a trivial problem, ideally extension should know nothing
about core's fields in the database and vice versa.
We had several options:
1. move data migration into an extension, it's a bad
option, because in migration we should drop
node.attributes.volumes column, it's a very bad
thing to do, because only core's migrations should
be responsible for managing of core's db schema
2. implement everything in the core, cannot be implemented
for the same reasons as for 1st option, in this
case we should run extension's db migration in
order to create required fields and then
in core migration hardcode table's name to migrate
the data
3. use shared table, in this case core's responsibility
is to just put all of the data from core's models
into predefined table and drop node.attributes.volumes column,
extension migration script's responsibility is to check
if in predefined table there are data for this specific
extension, and retrieve these data if there are any
We've decided to use shared table (3rd option) because it's
better option then two others.
Another change is we are not going to use extension version
as a prefix for extension tables. As result we will
not have two extension with the same name, but different
version installed at the same time. Using version in
table names dramatically increase complexity of extension
update.
Implements blueprint: volume-manager-refactoring
Change-Id: I6f03a535edab18e6d9e53a47fc4abdd381a3495f
8dd78be933