settingsLogin | Registersettings

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

0 votes

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'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.

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.

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked May 31, 2017 in openstack-dev by amrith.kumar_at_gmai (3,580 points)   2 3

2 Responses

0 votes

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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 31, 2017 by Monty_Taylor (22,780 points)   2 5 8
0 votes

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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded May 31, 2017 by amrith.kumar_at_gmai (3,580 points)   2 3
...