2011/5/25 Rick Harris <email address hidden>:
>> Is there a way to fix it?
> Probably the best way is to eyeball the schema in the DB and compare
> that to the migrations present in migrate_repo/versions. By looking at
> the differences, you should be able to 'guess' the proper version.
>
> For example, if in your schema `image_properties` is using `name`
> instead of `key`, then your DB version is at 6 (the latest and
> greatest).
>
> You can then create a migrate_version table and populate it like
>
> Glance
> Migrations|/usr/lib/pymodules/python2.6/glance/registry/db/migrate_repo|6
So you're suggesting we leave this up to users themselves to do this
manually? Is there any particular reason why the approach Nova took
isn't feasible for Glance?
2011/5/25 Rick Harris <email address hidden>: repo/versions. By looking at /usr/lib/ pymodules/ python2. 6/glance/ registry/ db/migrate_ repo|6
>> Is there a way to fix it?
> Probably the best way is to eyeball the schema in the DB and compare
> that to the migrations present in migrate_
> the differences, you should be able to 'guess' the proper version.
>
> For example, if in your schema `image_properties` is using `name`
> instead of `key`, then your DB version is at 6 (the latest and
> greatest).
>
> You can then create a migrate_version table and populate it like
>
> Glance
> Migrations|
So you're suggesting we leave this up to users themselves to do this
manually? Is there any particular reason why the approach Nova took
isn't feasible for Glance?
-- linux2go. dk/ www.ubuntu. com/ www.openstack. org/
Soren Hansen | http://
Ubuntu Developer | http://
OpenStack Developer | http://