On Sun, Jun 3, 2018 at 11:18 AM, Eli Mesika <emesika(a)redhat.com> wrote:
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.
Sounds quite problematic as not all upgrade scripts are written in a
re-entrant manner
>
>>
>>
>> @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.
>
>