>> You're right, it's not really achievable without moving to a schemaless >> persistence model. I'm fairly certain it was added to be humorous and >> should not be considered an outcome of that session. > > But we can avoid most data migrations by adding any required > conversion code into the objects DB layer, once we start using it. But > it might not be what we want.
Right, I'm sure it was added to the notes in response to discussion in the room about hating migrations in general. We can't avoid them entirely, but we do need to start moving away from making them monolithic and scary. This is important not only for performance when running migrations on large databases, but also for live upgrade. The general agreement from the summit sessions was that we need to make conductor able to tolerate all the schema versions from N-1 to N (where N is a release) so that it can be upgraded first, the schema next, and then (when possible) data migrations happen live instead of in bulk. --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
