On Wed, Sep 5, 2018 at 3:56 PM, Matt Riedemann <mriede...@gmail.com> wrote:
> On 9/5/2018 8:39 AM, Dan Smith wrote: > >> Why not? >> > > Because of the versions table as noted earlier. Up until this point no one > had mentioned that but it would be an issue. > > >> I think the safest/cleanest thing to do here is renumber placement-related >> migrations from 1, and provide a script or procedure to dump just the >> placement-related tables from the nova_api database to the new one (not >> including the sqlalchemy-migrate versions table). >> > > I'm OK with squashing/trimming/resetting the version to 1. What was not > mentioned earlier in this thread was (1) an acknowledgement that we'd need > to drop the versions table to reset the version in the new database and (2) > any ideas about providing scripts to help with the DB migration. > > I think it's safe too. Operators could just migrate the tables by using a read-only slave connection to a new DB and then using this script that would drop the non-needed tables. For people wanting to migrate tables, I think having placement versions being different is not a problem given the tables are the same. -Sylvain -- > > Thanks, > > Matt > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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
