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

Amrith Kumar amrith.kumar at gmail.com
Wed May 31 14:25:26 UTC 2017


Thx Monty, jroll, smcginnis, zzzeek_ ...


-amrith

--
Amrith Kumar
Phone: +1-978-563-9590


On Wed, May 31, 2017 at 10:17 AM, Monty Taylor <mordred at inaugust.com> wrote:

> 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170531/2d4d9c4f/attachment.html>


More information about the OpenStack-dev mailing list