[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 03.06.18 ] [098_ovirt_provider_ovn.use_ovn_provider ]
Merged
בתאריך יום א׳, 3 ביוני 2018, 17:23, מאת Arik Hadas :
> Testing: https://gerrit.ovirt.org/#/c/91898/
>
> On Sun, Jun 3, 2018 at 4:27 PM, Arik Hadas wrote:
>
>> I'm looking
>>
>> On Sun, Jun 3, 2018 at 3:52 PM, Gal Ben Haim wrote:
>>
>>> Specifically, it failed to unplug a nic from a VM.
>>>
>>>
>>> Suspected patches:
>>>
>>>
>>> https://gerrit.ovirt.org/#/c/91195/
>>>
>>> Link to Job:
>>>
>>>
>>> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/
>>>
>>> Link to all logs:
>>>
>>>
>>>
>>> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/artifact/exported-artifacts/basic-suit-master-el7/
>>>
>>> (Relevant) error snippet from the log:
>>>
>>>
>>>
>>> 2018-06-03 06:35:30,764-04 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HotUnplugNicVDSCommand] (default
>>> task-1) [32c965fd] FINISH, HotUnplugNicVDSCommand, return: , log id:
>>> 18d9b4e9
>>> 2018-06-03 06:35:30,764-04 DEBUG
>>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
>>> (default task-1) [32c965fd] method: runVdsCommand, params: [HotUnplugNic,
>>> VmNicDeviceVDSParameters:{hostId='d0f5b521-ed04-4b9e-9524-7f8d4be842d0',
>>> vm.vm_name='vm0', nic='VmNic:{id='9419aca6-2fae-4851-a902-a6b5a88ac691',
>>> vnicProfileId='8d12fcbb-23e8-432d-845a-ab2b97039955', speed='1',
>>> type='3', macAddress='00:1a:4a:16:01:0e', linked='true',
>>> vmId='ec4303e9-2b7a-451d-9f43-836c29767652', vmTemplateId='null'}',
>>> vmDevice='VmDevice:{id='VmDeviceId:{deviceId='9419aca6-2fae-4851-a902-a6b5a88ac691',
>>> vmId='ec4303e9-2b7a-451d-9f43-836c29767652'}', device='bridge',
>>> type='INTERFACE', specParams='[]', address='', managed='true',
>>> plugged='true', readOnly='false', deviceAlias='', customProperties='[]',
>>> snapshotId='null', logicalName='null', hostDevice='null'}'}], timeElapsed:
>>> 55ms
>>> 2018-06-03 06:35:30,765-04 ERROR
>>> [org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand]
>>> (default task-1) [32c965fd] Command
>>> 'org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand'
>>> failed: EngineException:
>>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>>> VDSGenericException: VDSErrorException: Failed to HotUnplugNicVDS, error =
>>> General Exception: ('macAddr',), code = 100 (Failed with error
>>> GeneralException and code 100)
>>> 2018-06-03 06:35:30,774-04 DEBUG
>>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
>>> (default task-1) [32c965fd] method: get, params:
>>> [d0f5b521-ed04-4b9e-9524-7f8d4be842d0], timeElapsed: 3ms
>>> 2018-06-03 06:35:30,781-04 DEBUG
>>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>>> (DefaultQuartzScheduler5) [] Rescheduling
>>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.refreshLightWeightData#-9223372036854775795
>>> as there is no unfired trigger.
>>> 2018-06-03 06:35:30,781-04 DEBUG
>>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>>> (DefaultQuartzScheduler6) [] Rescheduling
>>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterServiceSyncJob.refreshGlusterServices#-9223372036854775801
>>> as there is no unfired trigger.
>>> 2018-06-03 06:35:30,782-04 ERROR
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (default task-1) [32c965fd] EVENT_ID:
>>> NETWORK_DEACTIVATE_VM_INTERFACE_FAILURE(1,015), Failed to unplug Network
>>> Interface eth2 (VirtIO) from VM vm0. (User: admin@internal-authz)
>>> 2018-06-03 06:35:30,791-04 DEBUG
>>> [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
>>> (default task-1) [32c965fd] Compiled stored procedure. Call string i
>>>
>>>
>>>
>>>
>>>
>>> --
>>> *GAL bEN HAIM*
>>> RHV DEVOPS
>>>
>>
>>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/PGXYFLNE67WWNPMNJQQXHH5KV2D44XJK/
[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 03.06.18 ] [098_ovirt_provider_ovn.use_ovn_provider ]
Testing: https://gerrit.ovirt.org/#/c/91898/
On Sun, Jun 3, 2018 at 4:27 PM, Arik Hadas wrote:
> I'm looking
>
> On Sun, Jun 3, 2018 at 3:52 PM, Gal Ben Haim wrote:
>
>> Specifically, it failed to unplug a nic from a VM.
>>
>>
>> Suspected patches:
>>
>>
>> https://gerrit.ovirt.org/#/c/91195/
>>
>> Link to Job:
>>
>>
>> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/
>>
>> Link to all logs:
>>
>>
>> https://jenkins.ovirt.org/job/ovirt-master_change-queue-test
>> er/8019/artifact/exported-artifacts/basic-suit-master-el7/
>>
>> (Relevant) error snippet from the log:
>>
>>
>>
>> 2018-06-03 06:35:30,764-04 INFO
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HotUnplugNicVDSCommand] (default
>> task-1) [32c965fd] FINISH, HotUnplugNicVDSCommand, return: , log id: 18d9b4e9
>> 2018-06-03 06:35:30,764-04 DEBUG
>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
>> (default task-1) [32c965fd] method: runVdsCommand, params: [HotUnplugNic,
>> VmNicDeviceVDSParameters:{hostId='d0f5b521-ed04-4b9e-9524-7f8d4be842d0',
>> vm.vm_name='vm0', nic='VmNic:{id='9419aca6-2fae-4851-a902-a6b5a88ac691',
>> vnicProfileId='8d12fcbb-23e8-432d-845a-ab2b97039955', speed='1',
>> type='3', macAddress='00:1a:4a:16:01:0e', linked='true',
>> vmId='ec4303e9-2b7a-451d-9f43-836c29767652', vmTemplateId='null'}',
>> vmDevice='VmDevice:{id='VmDeviceId:{deviceId='9419aca6-2fae-4851-a902-a6b5a88ac691',
>> vmId='ec4303e9-2b7a-451d-9f43-836c29767652'}', device='bridge',
>> type='INTERFACE', specParams='[]', address='', managed='true',
>> plugged='true', readOnly='false', deviceAlias='', customProperties='[]',
>> snapshotId='null', logicalName='null', hostDevice='null'}'}], timeElapsed:
>> 55ms
>> 2018-06-03 06:35:30,765-04 ERROR
>> [org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand]
>> (default task-1) [32c965fd] Command
>> 'org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand'
>> failed: EngineException:
>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>> VDSGenericException: VDSErrorException: Failed to HotUnplugNicVDS, error =
>> General Exception: ('macAddr',), code = 100 (Failed with error
>> GeneralException and code 100)
>> 2018-06-03 06:35:30,774-04 DEBUG
>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
>> (default task-1) [32c965fd] method: get, params:
>> [d0f5b521-ed04-4b9e-9524-7f8d4be842d0], timeElapsed: 3ms
>> 2018-06-03 06:35:30,781-04 DEBUG
>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>> (DefaultQuartzScheduler5) [] Rescheduling
>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.refreshLightWeightData#-9223372036854775795
>> as there is no unfired trigger.
>> 2018-06-03 06:35:30,781-04 DEBUG
>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>> (DefaultQuartzScheduler6) [] Rescheduling
>> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterServiceSyncJob.refreshGlusterServices#-9223372036854775801
>> as there is no unfired trigger.
>> 2018-06-03 06:35:30,782-04 ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (default task-1) [32c965fd] EVENT_ID:
>> NETWORK_DEACTIVATE_VM_INTERFACE_FAILURE(1,015), Failed to unplug Network
>> Interface eth2 (VirtIO) from VM vm0. (User: admin@internal-authz)
>> 2018-06-03 06:35:30,791-04 DEBUG
>> [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
>> (default task-1) [32c965fd] Compiled stored procedure. Call string i
>>
>>
>>
>>
>>
>> --
>> *GAL bEN HAIM*
>> RHV DEVOPS
>>
>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WCWBPV5R4UQFBHRPKA4KSJHCLDNC2WHW/
[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 03.06.18 ] [098_ovirt_provider_ovn.use_ovn_provider ]
I'm looking
On Sun, Jun 3, 2018 at 3:52 PM, Gal Ben Haim wrote:
> Specifically, it failed to unplug a nic from a VM.
>
>
> Suspected patches:
>
>
> https://gerrit.ovirt.org/#/c/91195/
>
> Link to Job:
>
>
> https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/
>
> Link to all logs:
>
>
> https://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/8019/artifact/exported-artifacts/basic-suit-master-el7/
>
> (Relevant) error snippet from the log:
>
>
>
> 2018-06-03 06:35:30,764-04 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HotUnplugNicVDSCommand] (default
> task-1) [32c965fd] FINISH, HotUnplugNicVDSCommand, return: , log id: 18d9b4e9
> 2018-06-03 06:35:30,764-04 DEBUG
> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
> (default task-1) [32c965fd] method: runVdsCommand, params: [HotUnplugNic,
> VmNicDeviceVDSParameters:{hostId='d0f5b521-ed04-4b9e-9524-7f8d4be842d0',
> vm.vm_name='vm0', nic='VmNic:{id='9419aca6-2fae-4851-a902-a6b5a88ac691',
> vnicProfileId='8d12fcbb-23e8-432d-845a-ab2b97039955', speed='1',
> type='3', macAddress='00:1a:4a:16:01:0e', linked='true',
> vmId='ec4303e9-2b7a-451d-9f43-836c29767652', vmTemplateId='null'}',
> vmDevice='VmDevice:{id='VmDeviceId:{deviceId='9419aca6-2fae-4851-a902-a6b5a88ac691',
> vmId='ec4303e9-2b7a-451d-9f43-836c29767652'}', device='bridge',
> type='INTERFACE', specParams='[]', address='', managed='true',
> plugged='true', readOnly='false', deviceAlias='', customProperties='[]',
> snapshotId='null', logicalName='null', hostDevice='null'}'}], timeElapsed:
> 55ms
> 2018-06-03 06:35:30,765-04 ERROR
> [org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand]
> (default task-1) [32c965fd] Command
> 'org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand' failed:
> EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
> VDSGenericException: VDSErrorException: Failed to HotUnplugNicVDS, error =
> General Exception: ('macAddr',), code = 100 (Failed with error
> GeneralException and code 100)
> 2018-06-03 06:35:30,774-04 DEBUG
> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
> (default task-1) [32c965fd] method: get, params:
> [d0f5b521-ed04-4b9e-9524-7f8d4be842d0], timeElapsed: 3ms
> 2018-06-03 06:35:30,781-04 DEBUG
> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
> (DefaultQuartzScheduler5) [] Rescheduling
> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.refreshLightWeightData#-9223372036854775795
> as there is no unfired trigger.
> 2018-06-03 06:35:30,781-04 DEBUG
> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
> (DefaultQuartzScheduler6) [] Rescheduling
> DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterServiceSyncJob.refreshGlusterServices#-9223372036854775801
> as there is no unfired trigger.
> 2018-06-03 06:35:30,782-04 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-1) [32c965fd] EVENT_ID:
> NETWORK_DEACTIVATE_VM_INTERFACE_FAILURE(1,015), Failed to unplug Network
> Interface eth2 (VirtIO) from VM vm0. (User: admin@internal-authz)
> 2018-06-03 06:35:30,791-04 DEBUG
> [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
> (default task-1) [32c965fd] Compiled stored procedure. Call string i
>
>
>
>
>
> --
> *GAL bEN HAIM*
> RHV DEVOPS
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2KJPV6MML2K2YLIWAXD7OJXSTEFF3SR7/
[ovirt-devel] [ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 03.06.18 ] [098_ovirt_provider_ovn.use_ovn_provider ]
Specifically, it failed to unplug a nic from a VM.
Suspected patches:
https://gerrit.ovirt.org/#/c/91195/
Link to Job:
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/
Link to all logs:
https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/artifact/exported-artifacts/basic-suit-master-el7/
(Relevant) error snippet from the log:
2018-06-03 06:35:30,764-04 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotUnplugNicVDSCommand]
(default task-1) [32c965fd] FINISH, HotUnplugNicVDSCommand, return: ,
log id: 18d9b4e9
2018-06-03 06:35:30,764-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(default task-1) [32c965fd] method: runVdsCommand, params:
[HotUnplugNic,
VmNicDeviceVDSParameters:{hostId='d0f5b521-ed04-4b9e-9524-7f8d4be842d0',
vm.vm_name='vm0',
nic='VmNic:{id='9419aca6-2fae-4851-a902-a6b5a88ac691',
vnicProfileId='8d12fcbb-23e8-432d-845a-ab2b97039955', speed='1',
type='3', macAddress='00:1a:4a:16:01:0e', linked='true',
vmId='ec4303e9-2b7a-451d-9f43-836c29767652', vmTemplateId='null'}',
vmDevice='VmDevice:{id='VmDeviceId:{deviceId='9419aca6-2fae-4851-a902-a6b5a88ac691',
vmId='ec4303e9-2b7a-451d-9f43-836c29767652'}', device='bridge',
type='INTERFACE', specParams='[]', address='', managed='true',
plugged='true', readOnly='false', deviceAlias='',
customProperties='[]', snapshotId='null', logicalName='null',
hostDevice='null'}'}], timeElapsed: 55ms
2018-06-03 06:35:30,765-04 ERROR
[org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand]
(default task-1) [32c965fd] Command
'org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand'
failed: EngineException:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to HotUnplugNicVDS,
error = General Exception: ('macAddr',), code = 100 (Failed with error
GeneralException and code 100)
2018-06-03 06:35:30,774-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(default task-1) [32c965fd] method: get, params:
[d0f5b521-ed04-4b9e-9524-7f8d4be842d0], timeElapsed: 3ms
2018-06-03 06:35:30,781-04 DEBUG
[org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
(DefaultQuartzScheduler5) [] Rescheduling
DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.refreshLightWeightData#-9223372036854775795
as there is no unfired trigger.
2018-06-03 06:35:30,781-04 DEBUG
[org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
(DefaultQuartzScheduler6) [] Rescheduling
DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterServiceSyncJob.refreshGlusterServices#-9223372036854775801
as there is no unfired trigger.
2018-06-03 06:35:30,782-04 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-1) [32c965fd] EVENT_ID:
NETWORK_DEACTIVATE_VM_INTERFACE_FAILURE(1,015), Failed to unplug
Network Interface eth2 (VirtIO) from VM vm0. (User:
admin@internal-authz)
2018-06-03 06:35:30,791-04 DEBUG
[org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
(default task-1) [32c965fd] Compiled stored procedure. Call string i
--
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IKQ7TCXNH4YR4HVBIX6S5LCNBI7KNA56/
[ovirt-devel] Re: Recent upgrade issues caused by mess in database scripts
On Sun, 3 Jun 2018, 09:28 Tal Nisan, wrote: > > > On Sat, Jun 2, 2018 at 12:20 PM, Martin Perina 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? >> >> >> @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. >> > It is a bit problematic from my side, let's say script number 0110 makes > its way to 4.2 and has to be backported to 4.2.3.z but since two other > patches which include db scripts were not for 4.2.3.z but only 4.2, in this > way the script number has to be changed to 0090 in 4.2.3.z since the > upgrade script does not allow gaps of more than 10 in script numbers > It's OK to merge first 04_02_0090_xxx to 4.2 brach and afterwards the same script as 04_02_0070_xxx to 4.2.3.z branch. But after merging the patch to 4.2.3.z branch we need to have another patch to 4.2 branch which reorders scripts numbers in 4.2 branch to match those in 4.2.3.z >> 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. >> > > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ZZTVZRSPDMGN5RHNLGMETBT5WCODN7HD/
[ovirt-devel] Re: Recent upgrade issues caused by mess in database scripts
On Sun, Jun 3, 2018 at 11:18 AM, Eli Mesika wrote: > > > On Sat, Jun 2, 2018 at 12:20 PM, Martin Perina 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. >> > > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IX64KBRMSB2LN36Z5VJGEWAHC7DWG32R/
[ovirt-devel] Re: Recent upgrade issues caused by mess in database scripts
On Sat, Jun 2, 2018 at 12:20 PM, Martin Perina 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. > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/56CTWFLRP3VXSXYZOZ4PWORHTW5O4XWU/
[ovirt-devel] Re: Recent upgrade issues caused by mess in database scripts
On Sat, Jun 2, 2018 at 12:20 PM, Martin Perina 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? > > > @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. > It is a bit problematic from my side, let's say script number 0110 makes its way to 4.2 and has to be backported to 4.2.3.z but since two other patches which include db scripts were not for 4.2.3.z but only 4.2, in this way the script number has to be changed to 0090 in 4.2.3.z since the upgrade script does not allow gaps of more than 10 in script numbers > > 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. > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HIEB37Q4EKCFAHD3IURNJPBSCBIUD5BG/
