Open Stack

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.hill at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/15d3f6a9/attachment.html>