Preserve VDI tags on migration#7080
Conversation
last-genius
force-pushed
the
asv/vdi-preserve-tags
branch
from
2379577 to
cd3b25f
Compare
This is the first step towards allowing SMAPIv1/v3 code to preserve tags on VDI migrations. Also modifies the tests by adding the new 'tags' field. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech>
This allows for the storage backend to preserve tags after creating a destination VDI during migration. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech>
last-genius
force-pushed
the
asv/vdi-preserve-tags
branch
from
cd3b25f to
2443b77
Compare
This metadata is provided and meant to be managed by API clients. While it would be ideally a key-value datatype, tags can be used for this purpose while we think of a better solution |
last-genius
force-pushed
the
asv/vdi-preserve-tags
branch
from
2443b77 to
85e3c5a
Compare
I understand you've tested this on migrations from smapiv1 to smapiv1, what about in migrations to smapiv3 and the ones from smapiv3? |
SMAPI.VDI.create ignores the tags from vdi_info, so set them after the call Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech>
I haven't since I don't have the v3 drivers to test migration with. So I've just added the functions required to satisfy the interface requirements but did not call them anywhere. I've fixed that now, so tags should be preserved on snapshots/migration for v3 as well. |
last-genius
force-pushed
the
asv/vdi-preserve-tags
branch
from
85e3c5a to
76c7e26
Compare
3 participants
XCP-ng has a need for persistent VDI metadata (metadata that's preserved across snapshots/migrations). Currently none of the VDI fields (
other_config,sm_config,tags, etc.) persist across a migration. This is because the destination VDI is created by storage backends and then db-introduce'd into XAPI. Storage backends in turn consult only some of thevdi_infofields of the original VDI, preservingname_label,name_descriptionand some other fields, but not the fields that allow flexible metadata to be stored by clients.This PR allows storage backends to 1) consult
vdi.tags2) modifyvdi.tags. It then modifies the SMAPIv1 migrate code to copy over the tags from the source VDI to the destination after a migration.I've tested that this code preserves vdi tags after a migration, and this satisfies our need for persistent metadata. Opening as a draft, however, because I'm not sure if
tagsare the right place to store such metadata, and if the approach is the right one - thoughts?