- Infra - oVirt List Archives

[CQ]: 91886, 1 (ovirt-dwh) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 03 Jun '18

03 Jun '18

A system test invoked by the "ovirt-4.2" change queue including change 91886,1 (ovirt-dwh) failed. However, this change seems not to be the root cause for this failure. Change 91877,1 (ovirt-dwh) 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 91877,1 (ovirt-dwh) 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/91886/1 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/91877/1 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2279/

2 1

[CQ]: d00d8ca (stage-gh-stdci2) failed "dummy-master" system tests
by oVirt Jenkins 03 Jun '18

03 Jun '18

Change d00d8ca (stage-gh-stdci2) is probably the reason behind recent system test failures in the "dummy-master" 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://github.com/oVirt/stage-gh-stdci2/commit/d00d8cac105f7be15d2a0559522… For failed test results see: https://jenkins-staging.ovirt.org/job/dummy-master_change-queue-tester/149/

1 0

[CQ]: d00d8ca (stage-gh-stdci2) failed "dummy-master" system tests
by oVirt Jenkins 03 Jun '18

03 Jun '18

Change d00d8ca (stage-gh-stdci2) is probably the reason behind recent system test failures in the "dummy-master" 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://github.com/oVirt/stage-gh-stdci2/commit/d00d8cac105f7be15d2a0559522… For failed test results see: https://jenkins-staging.ovirt.org/job/dummy-master_change-queue-tester/147/

1 0

[JIRA] (OVIRT-1993) Looking for a new task to help with
by sailesh baskar (oVirt JIRA) 03 Jun '18

03 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1993?page=com.atlassian.jira.… ] sailesh baskar commented on OVIRT-1993: --------------------------------------- Couldn't find any results for first time task.. can you help me?? > Looking for a new task to help with > ----------------------------------- > > Key: OVIRT-1993 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1993 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sailesh baskar > Assignee: infra > > I would like to open a new ticket in the infrastructure team. Can you help > in the process? -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100086)

1 0

[JIRA] (OVIRT-1295) Add job to auto-rebase patches that are ready to be merged
by eyal edri (oVirt JIRA) 03 Jun '18

03 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1295?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1295: ----------------------------- Resolution: Won't Do Status: Done (was: To Do) > Add job to auto-rebase patches that are ready to be merged > ----------------------------------------------------------- > > Key: OVIRT-1295 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1295 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: eyal edri > Assignee: infra > Priority: Low > > We want to help stable branch maintainers to minimize the time needed for merging approved changes ( i.e CR +2 and VERIFY +1 ) and also to reduce the chance of merge conflicts. > A suggestion was made to create a job which will detect patches ready to be merged with the flags CR +2 and V +1 set and will auto rebase them, so when a maintainer is ready to submit a patch, hopefully the patch won't need a rebase and can be merged without further waiting for rebase or CI. > This approach might introduce challenges when working on patches that are dependent on other patches and a specific logic might be required to handle special cases. > [~tnisan(a)redhat.com][~ykaul][~dfediuck] I hope this conveys the need and requirement, please comment or add thoughts if I missed anything. > Initially we'll try enabling it for ovirt-engine on 4.1 branch. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100086)

1 0

[JIRA] (OVIRT-1295) Add job to auto-rebase patches that are ready to be merged
by Tal Nisan (oVirt JIRA) 03 Jun '18

03 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1295?page=com.atlassian.jira.… ] Tal Nisan commented on OVIRT-1295: ---------------------------------- How can I elaborate on the need? I never asked for it nor though it's needed :) Most of the time a rebase is not needed at all and we're good the way it is, you can close the ticket. > Add job to auto-rebase patches that are ready to be merged > ----------------------------------------------------------- > > Key: OVIRT-1295 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1295 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: eyal edri > Assignee: infra > Priority: Low > > We want to help stable branch maintainers to minimize the time needed for merging approved changes ( i.e CR +2 and VERIFY +1 ) and also to reduce the chance of merge conflicts. > A suggestion was made to create a job which will detect patches ready to be merged with the flags CR +2 and V +1 set and will auto rebase them, so when a maintainer is ready to submit a patch, hopefully the patch won't need a rebase and can be merged without further waiting for rebase or CI. > This approach might introduce challenges when working on patches that are dependent on other patches and a specific logic might be required to handle special cases. > [~tnisan(a)redhat.com][~ykaul][~dfediuck] I hope this conveys the need and requirement, please comment or add thoughts if I missed anything. > Initially we'll try enabling it for ovirt-engine on 4.1 branch. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100086)

1 0

[JIRA] (OVIRT-1549) run OST as a third-party tester for OpenStack's ovsdbapp
by eyal edri (oVirt JIRA) 03 Jun '18

03 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1549?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1549: ---------------------------------- [~danken(a)redhat.com] is this still needed? how often were we broken from this pkg or needed to consume it early so it will worth the time and resource invesment? > run OST as a third-party tester for OpenStack's ovsdbapp > -------------------------------------------------------- > > Key: OVIRT-1549 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1549 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > > https://github.com/openstack/ovsdbapp is a python binding for openvswitch-ovn. ovirt-provider-ovn is planning to use it instead of its own implementation. > ovsdbapp developers want to make sure they do not break the ovirt use case. I would like us to follow https://docs.openstack.org/infra/system-config/third_party.html and become a third-party tester of ovsdbapp. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100086)

1 0

[JIRA] (OVIRT-1767) Look into replacing gitweb for oVirt Gerrit
by eyal edri (oVirt JIRA) 03 Jun '18

03 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1767?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1767: ----------------------------- Priority: Low (was: Medium) > Look into replacing gitweb for oVirt Gerrit > ------------------------------------------- > > Key: OVIRT-1767 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1767 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Gerrit/git > Reporter: Barak Korren > Assignee: infra > Priority: Low > Labels: gerrit > > One of the faults of our Gerrit system is that the source browser look like it belongs to a different century. > There seems to be a Gerrit plugin which allows using Gitiles rather then gitweb in Gerrit: > https://gerrit-review.googlesource.com/Documentation/config-plugins.html#gi… > Gitiles itself seems to be a more modern Git UI then gitweb, at the very least is supports showing markdown files, which is a staple of modern source browsers: > https://gerrit.googlesource.com/gitiles/ > Another plugin to consider is the one for using GitBlit: > https://gerrit-review.googlesource.com/Documentation/config-plugins.html#gi… > Gitblit is another Java based Gir bowser: > http://gitblit.com/features.html -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100086)

1 0

[JIRA] (OVIRT-1811) tested rpms piling up
by eyal edri (oVirt JIRA) 03 Jun '18

03 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1811?page=com.atlassian.jira.… ] eyal edri commented on OVIRT-1811: ---------------------------------- [~bkorren(a)redhat.com] [~eyonasi(a)redhat.com] I guess this can linked to the retention ticket and closed as duplicate? > tested rpms piling up > --------------------- > > Key: OVIRT-1811 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1811 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: Repositories Mgmt > Reporter: sbonazzo > Assignee: infra > > /var/www/html/repos/ovirt/tested/master is now 351G > This causes > http://jenkins.ovirt.org/view/Publishers/job/ovirt_master_publish-rpms_nigh… > to run for one hour downloading obsolete code. > Do we have something cleaning up tested repos? > If not, can we get one? > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100086)

1 0

[JIRA] (OVIRT-1647) standard-enqueue was stuck while trying to fetch from Gerrit, timeout didn't work
by eyal edri (oVirt JIRA) 03 Jun '18

03 Jun '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1647?page=com.atlassian.jira.… ] eyal edri updated OVIRT-1647: ----------------------------- Resolution: Cannot Reproduce Status: Done (was: To Do) > standard-enqueue was stuck while trying to fetch from Gerrit, timeout didn't work > --------------------------------------------------------------------------------- > > Key: OVIRT-1647 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1647 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: oVirt CI > Reporter: Daniel Belenky > Assignee: infra > > `standard-enqueue` Job was stuck for 22 hours while trying to fetch repository from Gerrit. > For some reason, the timeout didn't work. I'm opening the ticket to track to issue. > Link to Job run: [http://jenkins.ovirt.org/job/standard-enqueue/4720/|standard-enqueue/4720] [Marked to keep forever] > Console output: (I've aborted the Job) > {code:java} > Triggered by Gerrit: https://gerrit.ovirt.org/81650 > [Pipeline] timestamps > [Pipeline] { > [Pipeline] ansiColor > [Pipeline] { > [Pipeline] node > 13:56:56 Running on vm0090.workers-phx.ovirt.org in /home/jenkins/workspace/standard-enqueue > [Pipeline] { > [Pipeline] stage > [Pipeline] { (loading code) > [Pipeline] dir > 13:56:56 Running in /home/jenkins/workspace/standard-enqueue/jenkins > [Pipeline] { > [Pipeline] checkout > 13:57:01 Cloning the remote Git repository > 13:57:01 Cloning repository https://gerrit.ovirt.org/jenkins > 13:57:01 > git init /home/jenkins/workspace/standard-enqueue/jenkins # timeout=10 > 13:57:01 Fetching upstream changes from https://gerrit.ovirt.org/jenkins > 13:57:01 > git --version # timeout=10 > 14:07:01 ERROR: Timeout after 10 minutes > Aborted by Daniel > {code} -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100086)

1 0