<HTML>
<HEAD>
<TITLE>Re: [Openstack] Recent changes to Ubuntu packaging wrt Glance, upgrading, database sync</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>So a useful question,<BR>
<BR>
What mistakes can we learn from this to make sure that this doesn’t happen again and that if it does we catch it much earlier?<BR>
<BR>
On 4/13/12 4:17 PM, "Adam Gandelman" <<a href="adamg@canonical.com">adamg@canonical.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi-<BR>
<BR>
We've added a patch to the Glance package in Ubuntu to help improve the<BR>
experience for users who are counting on a smooth upgrade from Diablo. <BR>
Since the release of Essex, I've been mostly focused on upgrade<BR>
testing. Things seem generally okay with the exception of Glance and<BR>
the way it manages its database and migrations. To ensure users can<BR>
reliably upgrade from Diablo, we've made a couple of changes that people<BR>
should know about as the end result is currently a bit different than<BR>
what you'd expect comparing to devstack/vanilla git repos.<BR>
<BR>
1. Disabled database auto-creation<BR>
<BR>
Glance is the only project that I know of that currently allows<BR>
sqlalchemy to auto-create database schema to match its database<BR>
models. This is great for the developer use-case, but really not ideal<BR>
for anyone who wishes to maintain their database for the long-term. The<BR>
original issue is that, on startup, glance-registry creates a database<BR>
schema that reflects its most recent view of the database. When it<BR>
does, the schema is created outside the view of migrate and the<BR>
migration repository cannot be used to incrementally upgrade/downgrade<BR>
the schema.<BR>
<BR>
Recent changes [1] in Glance provides a work-around to this isssue,<BR>
where we rely on glance-registry to automatically put the database under<BR>
version control after auto-creation and set its version to the most<BR>
recent (currently 13). This works fine for development but there are<BR>
important details in the migration code that don't actually end up in<BR>
the database schema when auto-created (FK constraints, for example)<BR>
because the migration scripts are not actually run.<BR>
<BR>
To avoid this entirely, we've prevented Glance from auto-migrating its<BR>
database and now require users to migrate the database on new install<BR>
and upgrade (via db_sync) in the same way Nova does.<BR>
<BR>
2. Sync'ing a new database.<BR>
<BR>
The changes also now allow users to set a specific version when<BR>
initializing version_control on a database with glance-manage, eg:<BR>
<BR>
glance-manage version_control 9<BR>
glance-manage db_sync<BR>
<BR>
This would properly migrate an non-version controlled Diablo database to<BR>
Essex. This is great, but it is still possible for Diablo users to<BR>
mistakenly start glance or run db_sync with no version control, and end<BR>
up in a situation where glance + migrate think it is up to date. In<BR>
reality the database is missing 3 migrations (one of which, 012 IDs to<BR>
UUIDs, is very essential!) To prevent this, the Ubuntu patch<BR>
additionally requires explicitly version_control'ing the database a<BR>
before db_sync on both new databases and during upgrades of databases<BR>
that are not already version_control'd.<BR>
<BR>
For example, on a new database:<BR>
<BR>
# Start from the beginning of the migration repositroy<BR>
glance-manage version_control 0<BR>
glance-manage db_sync<BR>
<BR>
or to upgrade from Diablo:<BR>
<BR>
# Was our database properly version controlled to begin with?<BR>
if ! glance-manage db_version ; then<BR>
# Set its version if not<BR>
glance-manage version_control 9<BR>
fi<BR>
# Run all migrations 10 to 13<BR>
glance-manage db_sync<BR>
<BR>
I understand this may have come a bit late to any users of the Precise<BR>
packages and I apologize for the lack of a heads up. I've filed a new<BR>
bug [2] about the split brain between glance-registry and and hope to<BR>
address this at the database management session [3] at ODS next week. <BR>
Anne Gentle has also proposed an update to the documentation with a note<BR>
about this. Please understand that our aim was to keep our patch delta<BR>
as minimal as possible in Ubuntu, but with the yesterday's Final Freeze<BR>
for the cycle 12.04 we needed something in place that ensures a sane<BR>
user story for previous users of Diablo and future Essex users alike.<BR>
<BR>
Cheers,<BR>
Adam<BR>
<BR>
[1] <a href="https://review.openstack.org/#/c/6166/">https://review.openstack.org/#/c/6166/</a><BR>
<a href="https://review.openstack.org/#/c/5980/1">https://review.openstack.org/#/c/5980/1</a><BR>
[2] <a href="https://bugs.launchpad.net/bugs/981081">https://bugs.launchpad.net/bugs/981081</a><BR>
[3] <a href="http://summit.openstack.org/sessions/view/36">http://summit.openstack.org/sessions/view/36</a><BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
Post to : <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><BR>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>