[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