[openstack-dev] Changing project schemas in patches; upgrade implications

Monty Taylor mordred at inaugust.com
Wed May 31 14:17:12 UTC 2017


On 05/31/2017 08:51 AM, Amrith Kumar wrote:
> This email thread relates to[1], a change that aims to improve cross-SQL 
> support in project schemas.
> 
> I want to explicitly exclude the notion of getting rid of support for 
> PostgreSQL in the underlying project schemas, a topic that was discussed 
> at the summit[2].
> 
> In this change, the author (Thomas Bechtold, copied on this thread) 
> makes the comment that the change "is not changing the schema. It just 
> avoids implicit type conversion".
> 
> It has long been my understanding that changes like this are not upgrade 
> friendly as it could lead to two installations both with, say version 37 
> or 38 of the schema, but different table structures. In effect, this 
> change breaks upgradability of systems.
> 
> i.e. a deployment which had a schema from the install of Ocata would 
> have a v38 table modules table with a default of 0 and one installed 
> with Pike (should this change be accepted) would have a modules table 
> with a default of False.

I agree that if that was the case this would be bad. But I don't think 
it's the case here.

The datatype in the model is already Boolean. So I believe that means 
this will be a tinyint in MySQL and likely a boolean in PG (I'm 
guessing) the only change here is to the SQLA layer in what is being 
used in code - and being more explicit seems good.

So I think this is a win.

> I'm raising this issue on the ML because the author also claims (albeit 
> not verified by me) that other projects have accepted changes like this.

Thanks! I think this is an area we need to be careful in - and extra 
eyeballs are a good thing.

> I submit to you that the upgrade friendly way of making this change 
> would be to propose a new version of the schema which alters all of 
> these tables and includes the correct default value. On a fresh install, 
> with no data, the upgrade step with this new schema version would bring 
> the table to the right default value and any system with that version of 
> the schema would have an identical set of defaults. Similarly any system 
> with v37 or 38 of the schema would have identical defaults.

Yes - I agree - that would definitely be the right way to do this if 
there was a model change.

> What's the advice of the community on this change; I've explicitly added 
> stable-maint-core as reviewers on this change as it does have stable 
> branch upgrade implications.
> 
> -amrith
> 
> [1] https://review.openstack.org/#/c/467080/
> ​[2]https://etherpad.openstack.org/p/BOS-postgresql
>> ​​
> 
> --
> Amrith Kumar
> Phone: +1-978-563-9590
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list