Your message dated Fri, 2 Aug 2019 14:29:13 +0200
with message-id <[email protected]>
and subject line Re: Bug#933652: Missing files in package: SQL upgrade scripts.
has caused the Debian Bug report #933652,
regarding Missing files in package: SQL upgrade scripts.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
933652: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933652
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: python3-cinder
Version: 2:13.0.3-1

Openstack components regularly prune their SQL upgrade scripts.

Here's an example of why this can be a problem (this isn't an actual real case, 
just for illustration purposes):
Say release no. 14 of openstack only contains SQL upgrade scripts that work 
from release 12 onwards. Trying to upgrade a release 11 database immediately to 
release 14 will not work and requires two separate steps, first installing 
release 12, then running update, then installing release 14, and running the 
SQL update again.

When trying to update an openstack running on debian 9 to one running on debian 
10, you can see why this is an issue:

For example, the 'cinder' package is updated from 'Newton' (DB version 79) 
immediately to 'Rocky'. "Rocky" database updates start at version 86 (the 'full 
database' script creates version 86).

That means the 79-80, 80-81, 81-82, ..., 84-85 scripts are missing from the 
/usr/lib/python3/dist-packages/cinder/db/sqlalchemy/migrate_repo/versions/ 
directory.

To solve this, you would probably have to copy over 073_cinder_init.py until 
085_modify_workers_updated_at.py from 
https://github.com/openstack/cinder/tree/stable/pike/cinder/db/sqlalchemy/migrate_repo/versions
 into the package, and remove the existing 085_cinder_init.py. ("Pike" is an 
openstack release in -between Newton (debian 9) and Rocky (debian 10)). Then, 
you have an unbroken chain of SQL update scripts that will update the database 
from version 79 all the way to version 123.

This problem is likely to also occur with various other openstack components.








--- End Message ---
--- Begin Message ---
On 8/1/19 2:53 PM, Louis Schmitz wrote:
> Package: python3-cinder
> 
> Version: 2:13.0.3-1
> 
>  
> 
> Openstack components regularly prune their SQL upgrade scripts.
> 
>  
> 
> Here’s an example of why this can be a problem (this isn’t an actual
> real case, just for illustration purposes):
> 
> Say release no. 14 of openstack only contains SQL upgrade scripts that
> work from release 12 onwards. Trying to upgrade a release 11 database
> immediately to release 14 will not work and requires two separate steps,
> first installing release 12, then running update, then installing
> release 14, and running the SQL update again.
> 
>  
> 
> When trying to update an openstack running on debian 9 to one running on
> debian 10, you can see why this is an issue:
> 
>  
> 
> For example, the ‘cinder’ package is updated from ‘Newton’ (DB version
> 79) immediately to ‘Rocky’. “Rocky” database updates start at version 86
> (the ‘full database’ script creates version 86).
> 
>  
> 
> That means the 79-80, 80-81, 81-82, ..., 84-85 scripts are missing from
> the
> /usr/lib/python3/dist-packages/cinder/db/sqlalchemy/migrate_repo/versions/
> directory.
> 
>  
> 
> To solve this, you would probably have to copy over 073_cinder_init.py
> until 085_modify_workers_updated_at.py from
> https://github.com/openstack/cinder/tree/stable/pike/cinder/db/sqlalchemy/migrate_repo/versionsinto
> the package, and remove the existing 085_cinder_init.py. (“Pike” is an
> openstack release in –between Newton (debian 9) and Rocky (debian 10)).
> Then, you have an unbroken chain of SQL update scripts that will update
> the database from version 79 all the way to version 123.
> 
>  
> 
> This problem is likely to also occur with various other openstack
> components.

Hi,

Unfortunately, what you are giving as an advice, may not be enough.
Indeed, on some components (like for example, Nova), the migration
scripts are importing some of the component code. So, just adding the
migration scripts may not be enough.

Unfortunately, there's no hope but upgrading from one version to the
next, using the backports repositories that the OpenStack team provides.

I would strongly advice that you complain about all of this upstream,
explaining that the way they release stuff is making your life horrible,
and that this would be too much work for downstream to fix and test
upgrades.

Alternatively, you could also do the work and propose patches against
the Debian packages. But at this point, I don't have the time for doing
this myself, and as much as I know, none of the team members either.

I'm therefore closing this bug.

Cheers,

Thomas Goirand (zigo)

--- End Message ---

Reply via email to