There is the database migration for datastores. We should add a function to back fill the existing data with either a dummy data or set it to 'mysql' as that was the only possibility before data stores. On Dec 18, 2013 3:23 PM, "Greg Hill" <greg.h...@rackspace.com> wrote:
> I've been working on fixing a bug related to migrating existing > installations to the new datastore code: > > https://bugs.launchpad.net/trove/+bug/1259642 > > The basic gist is that existing instances won't have any data in the > datastore_version_id field in the database unless we somehow populate that > data during migration, and not having that data populated breaks a lot of > things (including the ability to list instances or delete or resize old > instances). It's impossible to populate that data in an automatic, generic > way, since it's highly vendor-dependent on what database and version they > currently support, and there's not enough data in the older schema to > populate the new tables automatically. > > So far, we've come up with some non-optimal solutions: > > 1. The first iteration was to assume 'mysql' as the database manager on > instances without a datastore set. > 2. The next iteration was to make the default value be configurable in > trove.conf, but default to 'mysql' if it wasn't set. > 3. It was then proposed that we could just use the 'default_datastore' > value from the config, which may or may not be set by the operator. > > My problem with any of these approaches beyond the first is that > requiring people to populate config values in order to successfully migrate > to the newer code is really no different than requiring them to populate > the new database tables with appropriate data and updating the existing > instances with the appropriate values. Either way, it's now highly > dependent on people deploying the upgrade to know about this change and > react accordingly. > > Does anyone have a better solution that we aren't considering? Is this > even worth the effort given that trove has so few current deployments that > we can just make sure everyone is populating the new tables as part of > their upgrade path and not bother fixing the code to deal with the legacy > data? > > Greg > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
