I'm working on a migrate utility for https://review.openstack.org/#/c/363415 . Quick summary: that means moving resource.properties_data and event.properties_data to a new table, resource_properties_data. Migrating to the new model is easy. The questions come up with the inverse operation.
1) Would we even want to support undoing a migrate? I lean towards "no" but if the answer is "yes," the next question comes up: 2) We need to indicate somewhere which resource_properties_data rows were migrated to begin with. The reason being, we shouldn't support trying to migrate recent (non-legacy) resource_properties_data data backwards into the legacy columns in the resource and event tables. There are a couple of ways to do that: a) add an is_legacy column to resource_properties_data b) add another table which stores id's of those that events and resources that have been migrated or c) for the super paranoid same as b) only also store an extra copy of the original data (partially motivated by the unfortunate situation we have of events.properties_data being a PickleType and something going wrong with the conversion to a Json column, not that I see that happening). c) also opens up another can of worms with encrypt/decrypt operations. I lean towards "b" here (well, after null set ;-). Thanks, --Crag __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev