- Infra - oVirt List Archives

[JIRA] (OVIRT-2131) Master CQ: Cannot find a valid baseurl for repo: base/7/x86_64
by Dafna Ron (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2131?page=com.atlassian.jira.… ] Dafna Ron commented on OVIRT-2131: ---------------------------------- I think this is an external repo which we should be re-blocking by reverting change that eyal did. > Master CQ: Cannot find a valid baseurl for repo: base/7/x86_64 > -------------------------------------------------------------- > > Key: OVIRT-2131 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2131 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: cq-issue-traking, ost_failures, ost_infra > > test failed. looking into it > '11:12:55 [basic-suit] > 11:12:55 [basic-suit] - STDERR > 11:12:55 [basic-suit] + HUGEPAGES=3 > 11:12:55 [basic-suit] + yum update -y iptables > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] One of the configured repositories failed (Unknown), > 11:12:55 [basic-suit] and yum doesn't have enough cached data to continue. At this point the only > 11:12:55 [basic-suit] safe thing yum can do is fail. There are a few ways to work "fix" this: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 1. Contact the upstream for the repository and get them to fix the problem. > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 2. Reconfigure the baseurl/etc. for the repository, to point to a working > 11:12:55 [basic-suit] upstream. This is most often useful if you are using a newer > 11:12:55 [basic-suit] distribution release than is supported by the repository (and the > 11:12:55 [basic-suit] packages for the previous distribution release still work). > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 3. Run the command with the repository temporarily disabled > 11:12:55 [basic-suit] yum --disablerepo=<repoid> ... > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 4. Disable the repository permanently, so yum won't use it by default. Yum > 11:12:55 [basic-suit] will then just ignore the repository until you permanently enable it > 11:12:55 [basic-suit] again or use --enablerepo for temporary usage: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] yum-config-manager --disable <repoid> > 11:12:55 [basic-suit] or > 11:12:55 [basic-suit] subscription-manager repos --disable=<repoid> > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 5. Configure the failing repository to be skipped, if it is unavailable. > 11:12:55 [basic-suit] Note that yum will try to contact the repo. when it runs most commands, > 11:12:55 [basic-suit] so will have to try and fail each time (and thus. yum will be be much > 11:12:55 [basic-suit] slower). If it is a very temporary problem though, this is often a nice > 11:12:55 [basic-suit] compromise: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] Cannot find a valid baseurl for repo: base/7/x86_64 > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] * [Thread-3] Deploy VM lago-basic-suite-master-host-1: ERROR (in 0:00:30) > 11:12:55 [basic-suit] Error while running thread > 11:12:55 [basic-suit] Traceback (most recent call last): > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue > 11:12:55 [basic-suit] queue.put({'return': func()}) > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1660, in _deploy_host > 11:12:55 [basic-suit] host.name(), > 11:12:55 [basic-suit] RuntimeError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-master_change-queue-tester_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_host_el7.sh failed with status 1 on lago-basic-suite-master-host-1 > 11:12:55 [basic-suit] Error while running thread > 11:12:55 [basic-suit] Traceback (most recent call last): > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue > 11:12:55 [basic-suit] queue.put({'return': func()}) > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1660, in _deploy_host > 11:12:55 [basic-suit] host.name(), > 11:12:55 [basic-suit] RuntimeError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-master_change-queue-tester_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_host_el7.sh failed with status 1 on lago-basic-suite-master-host-1 > 11:12:57 [upgrade-from-release-suit] Finish: creating root cache > 11:12:57 [upgrade-from-release-suit] Finish: chroot init > 11:12:57 [upgrade-from-release-suit] INFO: Installed packages: > 11:12:57 [upgrade-from-release-suit] Finish: run > 11:12:57 [upgrade-from-release-suit] Init took 208 seconds > 11:12:57 [upgrade-from-release-suit] ============================' -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2131) Master CQ: Cannot find a valid baseurl for repo: base/7/x86_64
by Dafna Ron (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2131?page=com.atlassian.jira.… ] Dafna Ron updated OVIRT-2131: ----------------------------- Labels: cq-issue-traking ost_failures ost_infra (was: cq-issue-traking ost_failures ost_infra ost_race) > Master CQ: Cannot find a valid baseurl for repo: base/7/x86_64 > -------------------------------------------------------------- > > Key: OVIRT-2131 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2131 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: cq-issue-traking, ost_failures, ost_infra > > test failed. looking into it > '11:12:55 [basic-suit] > 11:12:55 [basic-suit] - STDERR > 11:12:55 [basic-suit] + HUGEPAGES=3 > 11:12:55 [basic-suit] + yum update -y iptables > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] One of the configured repositories failed (Unknown), > 11:12:55 [basic-suit] and yum doesn't have enough cached data to continue. At this point the only > 11:12:55 [basic-suit] safe thing yum can do is fail. There are a few ways to work "fix" this: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 1. Contact the upstream for the repository and get them to fix the problem. > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 2. Reconfigure the baseurl/etc. for the repository, to point to a working > 11:12:55 [basic-suit] upstream. This is most often useful if you are using a newer > 11:12:55 [basic-suit] distribution release than is supported by the repository (and the > 11:12:55 [basic-suit] packages for the previous distribution release still work). > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 3. Run the command with the repository temporarily disabled > 11:12:55 [basic-suit] yum --disablerepo=<repoid> ... > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 4. Disable the repository permanently, so yum won't use it by default. Yum > 11:12:55 [basic-suit] will then just ignore the repository until you permanently enable it > 11:12:55 [basic-suit] again or use --enablerepo for temporary usage: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] yum-config-manager --disable <repoid> > 11:12:55 [basic-suit] or > 11:12:55 [basic-suit] subscription-manager repos --disable=<repoid> > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 5. Configure the failing repository to be skipped, if it is unavailable. > 11:12:55 [basic-suit] Note that yum will try to contact the repo. when it runs most commands, > 11:12:55 [basic-suit] so will have to try and fail each time (and thus. yum will be be much > 11:12:55 [basic-suit] slower). If it is a very temporary problem though, this is often a nice > 11:12:55 [basic-suit] compromise: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] Cannot find a valid baseurl for repo: base/7/x86_64 > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] * [Thread-3] Deploy VM lago-basic-suite-master-host-1: ERROR (in 0:00:30) > 11:12:55 [basic-suit] Error while running thread > 11:12:55 [basic-suit] Traceback (most recent call last): > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue > 11:12:55 [basic-suit] queue.put({'return': func()}) > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1660, in _deploy_host > 11:12:55 [basic-suit] host.name(), > 11:12:55 [basic-suit] RuntimeError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-master_change-queue-tester_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_host_el7.sh failed with status 1 on lago-basic-suite-master-host-1 > 11:12:55 [basic-suit] Error while running thread > 11:12:55 [basic-suit] Traceback (most recent call last): > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue > 11:12:55 [basic-suit] queue.put({'return': func()}) > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1660, in _deploy_host > 11:12:55 [basic-suit] host.name(), > 11:12:55 [basic-suit] RuntimeError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-master_change-queue-tester_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_host_el7.sh failed with status 1 on lago-basic-suite-master-host-1 > 11:12:57 [upgrade-from-release-suit] Finish: creating root cache > 11:12:57 [upgrade-from-release-suit] Finish: chroot init > 11:12:57 [upgrade-from-release-suit] INFO: Installed packages: > 11:12:57 [upgrade-from-release-suit] Finish: run > 11:12:57 [upgrade-from-release-suit] Init took 208 seconds > 11:12:57 [upgrade-from-release-suit] ============================' -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2131) Master CQ: Cannot find a valid baseurl for repo: base/7/x86_64
by Dafna Ron (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2131?page=com.atlassian.jira.… ] Dafna Ron updated OVIRT-2131: ----------------------------- Labels: cq-issue-traking ost_failures ost_infra ost_race (was: cq-issue-traking ost_failures ost_infra) > Master CQ: Cannot find a valid baseurl for repo: base/7/x86_64 > -------------------------------------------------------------- > > Key: OVIRT-2131 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2131 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: cq-issue-traking, ost_failures, ost_infra, ost_race > > test failed. looking into it > '11:12:55 [basic-suit] > 11:12:55 [basic-suit] - STDERR > 11:12:55 [basic-suit] + HUGEPAGES=3 > 11:12:55 [basic-suit] + yum update -y iptables > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] One of the configured repositories failed (Unknown), > 11:12:55 [basic-suit] and yum doesn't have enough cached data to continue. At this point the only > 11:12:55 [basic-suit] safe thing yum can do is fail. There are a few ways to work "fix" this: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 1. Contact the upstream for the repository and get them to fix the problem. > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 2. Reconfigure the baseurl/etc. for the repository, to point to a working > 11:12:55 [basic-suit] upstream. This is most often useful if you are using a newer > 11:12:55 [basic-suit] distribution release than is supported by the repository (and the > 11:12:55 [basic-suit] packages for the previous distribution release still work). > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 3. Run the command with the repository temporarily disabled > 11:12:55 [basic-suit] yum --disablerepo=<repoid> ... > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 4. Disable the repository permanently, so yum won't use it by default. Yum > 11:12:55 [basic-suit] will then just ignore the repository until you permanently enable it > 11:12:55 [basic-suit] again or use --enablerepo for temporary usage: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] yum-config-manager --disable <repoid> > 11:12:55 [basic-suit] or > 11:12:55 [basic-suit] subscription-manager repos --disable=<repoid> > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] 5. Configure the failing repository to be skipped, if it is unavailable. > 11:12:55 [basic-suit] Note that yum will try to contact the repo. when it runs most commands, > 11:12:55 [basic-suit] so will have to try and fail each time (and thus. yum will be be much > 11:12:55 [basic-suit] slower). If it is a very temporary problem though, this is often a nice > 11:12:55 [basic-suit] compromise: > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] Cannot find a valid baseurl for repo: base/7/x86_64 > 11:12:55 [basic-suit] > 11:12:55 [basic-suit] * [Thread-3] Deploy VM lago-basic-suite-master-host-1: ERROR (in 0:00:30) > 11:12:55 [basic-suit] Error while running thread > 11:12:55 [basic-suit] Traceback (most recent call last): > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue > 11:12:55 [basic-suit] queue.put({'return': func()}) > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1660, in _deploy_host > 11:12:55 [basic-suit] host.name(), > 11:12:55 [basic-suit] RuntimeError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-master_change-queue-tester_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_host_el7.sh failed with status 1 on lago-basic-suite-master-host-1 > 11:12:55 [basic-suit] Error while running thread > 11:12:55 [basic-suit] Traceback (most recent call last): > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue > 11:12:55 [basic-suit] queue.put({'return': func()}) > 11:12:55 [basic-suit] File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1660, in _deploy_host > 11:12:55 [basic-suit] host.name(), > 11:12:55 [basic-suit] RuntimeError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-master_change-queue-tester_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_host_el7.sh failed with status 1 on lago-basic-suite-master-host-1 > 11:12:57 [upgrade-from-release-suit] Finish: creating root cache > 11:12:57 [upgrade-from-release-suit] Finish: chroot init > 11:12:57 [upgrade-from-release-suit] INFO: Installed packages: > 11:12:57 [upgrade-from-release-suit] Finish: run > 11:12:57 [upgrade-from-release-suit] Init took 208 seconds > 11:12:57 [upgrade-from-release-suit] ============================' -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2141) dwh fails on prepare_migration_attachments_ipv4
by Barak Korren (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2141?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-2141: ------------------------------------- [~dron] I think you should already make a ticket tracking race conditions on the relevant test and link it as a "causes" ticket to this one. > dwh fails on prepare_migration_attachments_ipv4 > ------------------------------------------------ > > Key: OVIRT-2141 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2141 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_infra, ost_race > > Change 91956,1 (ovirt-dwh) is probably the reason behind recent system test > failures in the "ovirt-4.2" change queue and needs to be fixed. > This change had been removed from the testing queue. Artifacts build from this > change will not be released until it is fixed. > For further details about the change see: > https://gerrit.ovirt.org/#/c/91956/1 > For failed test results see: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ > I cannot see an actual error. > I suspect that the issue is that we fail to get stats at times: > GetStatsAsyncVDSCommand(HostName = lago-basic-suite-4-2-host-0 > the host become non-responsive and tests fail. > I re-added the change since I want to see if it fails again on the same issue. > however, we still need to look into why the vds is not responding. > I kept the build so that we can look at logs: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2141) dwh fails on prepare_migration_attachments_ipv4
by Dafna Ron (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2141?page=com.atlassian.jira.… ] Dafna Ron updated OVIRT-2141: ----------------------------- Resolution: Fixed Status: Done (was: To Do) race condition > dwh fails on prepare_migration_attachments_ipv4 > ------------------------------------------------ > > Key: OVIRT-2141 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2141 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_infra, ost_race > > Change 91956,1 (ovirt-dwh) is probably the reason behind recent system test > failures in the "ovirt-4.2" change queue and needs to be fixed. > This change had been removed from the testing queue. Artifacts build from this > change will not be released until it is fixed. > For further details about the change see: > https://gerrit.ovirt.org/#/c/91956/1 > For failed test results see: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ > I cannot see an actual error. > I suspect that the issue is that we fail to get stats at times: > GetStatsAsyncVDSCommand(HostName = lago-basic-suite-4-2-host-0 > the host become non-responsive and tests fail. > I re-added the change since I want to see if it fails again on the same issue. > however, we still need to look into why the vds is not responding. > I kept the build so that we can look at logs: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2141) dwh fails on prepare_migration_attachments_ipv4
by Dafna Ron (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2141?page=com.atlassian.jira.… ] Dafna Ron commented on OVIRT-2141: ---------------------------------- the change passed on the second time. this seemed to have been a race condition. closing this for now but if happens again we should look closer at the test. > dwh fails on prepare_migration_attachments_ipv4 > ------------------------------------------------ > > Key: OVIRT-2141 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2141 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_infra, ost_race > > Change 91956,1 (ovirt-dwh) is probably the reason behind recent system test > failures in the "ovirt-4.2" change queue and needs to be fixed. > This change had been removed from the testing queue. Artifacts build from this > change will not be released until it is fixed. > For further details about the change see: > https://gerrit.ovirt.org/#/c/91956/1 > For failed test results see: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ > I cannot see an actual error. > I suspect that the issue is that we fail to get stats at times: > GetStatsAsyncVDSCommand(HostName = lago-basic-suite-4-2-host-0 > the host become non-responsive and tests fail. > I re-added the change since I want to see if it fails again on the same issue. > however, we still need to look into why the vds is not responding. > I kept the build so that we can look at logs: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2141) dwh fails on prepare_migration_attachments_ipv4
by Dafna Ron (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2141?page=com.atlassian.jira.… ] Dafna Ron updated OVIRT-2141: ----------------------------- Labels: ost_failures ost_infra ost_race (was: ost_failures) > dwh fails on prepare_migration_attachments_ipv4 > ------------------------------------------------ > > Key: OVIRT-2141 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2141 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Dafna Ron > Assignee: infra > Labels: ost_failures, ost_infra, ost_race > > Change 91956,1 (ovirt-dwh) is probably the reason behind recent system test > failures in the "ovirt-4.2" change queue and needs to be fixed. > This change had been removed from the testing queue. Artifacts build from this > change will not be released until it is fixed. > For further details about the change see: > https://gerrit.ovirt.org/#/c/91956/1 > For failed test results see: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ > I cannot see an actual error. > I suspect that the issue is that we fail to get stats at times: > GetStatsAsyncVDSCommand(HostName = lago-basic-suite-4-2-host-0 > the host become non-responsive and tests fail. > I re-added the change since I want to see if it fails again on the same issue. > however, we still need to look into why the vds is not responding. > I kept the build so that we can look at logs: > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2299/ -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[CQ]: 91968, 4 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 06 Jun '18

06 Jun '18

A system test invoked by the "ovirt-master" change queue including change 91968,4 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 91888,3 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 91888,3 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/91968/4 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/91888/3 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8068/

1 0

[JIRA] (OVIRT-2144) Extend "build_reposync_config.sh" to support a suite as an input
by Gal Ben Haim (oVirt JIRA) 06 Jun '18

06 Jun '18

Gal Ben Haim created OVIRT-2144: ----------------------------------- Summary: Extend "build_reposync_config.sh" to support a suite as an input Key: OVIRT-2144 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2144 Project: oVirt - virtualization made easy Issue Type: Improvement Components: OST Reporter: Gal Ben Haim Assignee: infra As an OST maintainer, I would like to generate a reposync--config for a suite, without getting into the low level details such as lago-image, lago-repo, which packages the suite uses etc... -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0

[JIRA] (OVIRT-2143) gerrit.ovirt.org response time
by eyal edri (oVirt JIRA) 06 Jun '18

06 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2143?page=com.atlassian.jira.… ] eyal edri reassigned OVIRT-2143: -------------------------------- Assignee: Evgheni Dereveanchin (was: infra) > gerrit.ovirt.org response time > ------------------------------ > > Key: OVIRT-2143 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2143 > Project: oVirt - virtualization made easy > Issue Type: Outage > Reporter: Eitan Raviv > Assignee: Evgheni Dereveanchin > Priority: High > > Hi, > In the past few weeks me and other team members are experiencing > considerable slowness in response time of the gerrit.ovirt.org GUI app > in the browser when fetching a patch summary page or one of the files > in the patch. Wait times of up to 15 seconds are not uncommon even for > small patches, and up to a 50 sec delay was experienced today with > recently closed patches from the past week. > Any help would be highly appreciated. > Thanks > Eitan -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087)

1 0