<p dir="ltr">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.</p>

<div class="gmail_quote">On Dec 18, 2013 3:23 PM, "Greg Hill" <<a href="mailto:greg.hill@rackspace.com">greg.hill@rackspace.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div style="word-wrap:break-word">
I've been working on fixing a bug related to migrating existing installations to the new datastore code:
<div><br>
</div>
<div><a href="https://bugs.launchpad.net/trove/+bug/1259642" target="_blank">https://bugs.launchpad.net/trove/+bug/1259642</a></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So far, we've come up with some non-optimal solutions:</div>
<div><br>
</div>
<div>1. The first iteration was to assume 'mysql' as the database manager on instances without a datastore set.</div>
<div>2. The next iteration was to make the default value be configurable in trove.conf, but default to 'mysql' if it wasn't set.</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Greg</div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>