December 2016 - Infra - oVirt List Archives

oVirt infra daily report - unstable production jobs - 160
by jenkins＠jenkins.phx.ovirt.org 06 Dec '16

06 Dec '16

Good morning! Attached is the HTML page with the jenkins status report. You can see it also here: - http://jenkins.ovirt.org/job/system_jenkins-report/160//artifact/exported-a… Cheers, Jenkins

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] Barak Korren reassigned OVIRT-909: ---------------------------------- Assignee: Barak Korren (was: infra) > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: Barak Korren > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-909: ------------------------------------ [~fdeutsch] sudo rm will just mean you need to re-clone everything from Gerrit every time the job runs, its a waste of time... I will try to send a patch for this soon > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: infra > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by eyal edri [Administrator] (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-909: ------------------------------------------------- [~bkorren(a)redhat.com] can you help with the patch to fix mock cleanup? I'm not sure [~ederevea] is familiar enough with standard ci and we need it fixed soon so node jobs can run > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: infra > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-909) Several git errors in several jobs
by Fabian Deutsch (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-909?page=com.atlassian.jira.p… ] Fabian Deutsch commented on OVIRT-909: -------------------------------------- Could be the case, because libvirt is involved, which might also touch this directory, which could be setting different users. What about sudo rm'ing the workspace? I'm open to any fix for this issue. > Several git errors in several jobs > ---------------------------------- > > Key: OVIRT-909 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-909 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Jenkins > Reporter: Fabian Deutsch > Assignee: infra > Priority: Highest > > The following jobs all had the same git issue, first cloning then cleaning: > * * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > * http://jenkins.ovirt.org/user/fabiand/my-views/view/Unstable/job/ovirt-node… > This happened several times in the last weeks. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-911) Move repo closure to run in STD-CI
by Gil Shinar (oVirt JIRA) 06 Dec '16

06 Dec '16

Gil Shinar created OVIRT-911: -------------------------------- Summary: Move repo closure to run in STD-CI Key: OVIRT-911 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-911 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Gil Shinar Assignee: infra Repo closure jobs are currently running on VMs. We would like to change these jobs to run inside mocks as STD-CI. -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-910: ------------------------------------ the problem with logs is that you need to get then "hot" be cause they may disappear fast... Older slave log (fc24-vm15.phx.ovirt.org) http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5915/ {code} ... 12:01:51 Start: unpacking root cache 12:02:06 Finish: unpacking root cache ... 12:02:07 Init took 17 seconds {code} Newer slave log (vm0125.workers-phx.ovirt.org) http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5916/ {code} ... 12:04:19 Start: unpacking root cache 12:05:15 Finish: unpacking root cache ... 12:05:16 Init took 57 seconds {code} Then again, on (newer) vm0130.workers-phx.ovirt.org: http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/5916/ {code} ... 12:02:45 Start: unpacking root cache 12:03:09 Finish: unpacking root cache ... 12:03:09 Init took 24 seconds {code} So not a 100% consistent result, still, we should find out how to get those 40 seconds back... BTW I was sure the local disk was mounted on older slaves with noatime, looks like that is not the case, maybe we should fix that... > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-904) False CI-1 due to unreachable copr-be.cloud.fedoraproject.org
by Greg Sheremeta (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-904?page=com.atlassian.jira.p… ] Greg Sheremeta commented on OVIRT-904: -------------------------------------- I maintain patternfly on copr. No one else uses it, so we can move it anywhere that makes sense. > False CI-1 due to unreachable copr-be.cloud.fedoraproject.org > ------------------------------------------------------------- > > Key: OVIRT-904 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-904 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: danken > Assignee: infra > > Many patches on > https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to > failure: repodata/repomd.xml from patternfly: [Errno 256] No more > mirrors to try. > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-…: > [Errno 14] curl#7 - "Failed connect to > copr-be.cloud.fedoraproject.org:80; No route to host" > http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-… -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Evgheni Dereveanchin (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Evgheni Dereveanchin commented on OVIRT-910: -------------------------------------------- [~bkorren(a)redhat.com] some logs would be helpful :) Older slaves with local disk hook use ext4 on the secondary disk while newer ones write to rootfs which is XFS. I can try launching a dozen ext4 VMs so that we can compare performance. > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0

[JIRA] (OVIRT-910) mock_runner.sh seems to run slower on newer slaves
by Barak Korren (oVirt JIRA) 06 Dec '16

06 Dec '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-910?page=com.atlassian.jira.p… ] Barak Korren updated OVIRT-910: ------------------------------- Description: After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock was: After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. I suspect this may be because the older slaves have a different FS mounted on /var/lib/mock > mock_runner.sh seems to run slower on newer slaves > -------------------------------------------------- > > Key: OVIRT-910 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-910 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Jenkins > Reporter: Barak Korren > Assignee: infra > > After implementing speedup improvements for mock_runner.sh (Specifically enabling it to deploy the chroot by extracting a tarball as opposed to installing it with yum every time), I started monitoring run times for vdsm check_patch jobs. > I've noticed that jobs that are running on the old slaves (fc24-vm*) seem to initialize mock faster then ones running on new slaves (vm*) - 17seconds vs 57 seconds respectively. > I suspect this may be because the older slaves have a different FS mounted on /var/cache/mock -- This message was sent by Atlassian JIRA (v1000.610.2#100023)

1 0