On Sat, Jun 2, 2018 at 12:20 PM, Martin Perina <mperina(a)redhat.com> wrote:
Hi,
recently [1], [2] were raised, but the main reason for those bugs was the
we are no paying enough attention to consequences when doing backports.
Below are two examples which we need to pay more attention to:
1. Database upgrade scripts naming and numbering
- there's no problem if the same script has different name or number
between y-streams (for example 4.3 and 4.2), but names and number need to
match between z-streams
- if we are going to do async release (for example 4.2.3.z) and we
need to backport to async branch patch which includes db upgrade script, we
need to make sure to align db scripts in branch from which next z-stream
will be built (for example 4.2, patch [3] can be used as an example how to
fix this issue)
2. Use the same name of database upgrade script when doing backports
- when backporting some patches to z-stream branch please use the same
db script name and change only db script number as needed, otherwise
backports are quite confusing (for example [4] and [5])
Patch [3] fixes the situation, so when included into 4.2.4 build it should
allow smooth upgrade from 4.2.3.z to 4.2.4, but users which already
performed upgrade are in trouble. @Eli is there any way how we can force
execution of db scripts, which were skipped due to the mess in names
between 4.2.3.z and 4.2.4 to help users which have already broken database?
unfortunately, those should be run manually or merge all to one re-entrant
script and add it as an additional upgrade script.
@Tal/@Piotr, could you please pay even more attention when merging patches
containing db scripts to z-stream async branches (normal branch, for
example ovirt-engine-4.2, should be fine, but ovirt-engine-4.2.3.z requires
more attention)? I agree that developer who backports the patch should
handle the situation (feel free to ask infra team if unsure about
consequences), but you are the last safety check we have.
Thanks a lot
Martin
[1]
https://bugzilla.redhat.com/1583562
[2]
https://bugzilla.redhat.com/1583664
[3]
https://gerrit.ovirt.org/91874
[4]
https://gerrit.ovirt.org/90695
[5]
https://gerrit.ovirt.org/90698
--
Martin Perina
Associate Manager, Software Engineering
Red Hat Czech s.r.o.