Re: New design for the Gerrit UI
Looks very nice! On May 3, 2017 7:20 PM, "Evgheni Dereveanchin" wrote: > Hi everyone, > > The Infra team is working on customizing the look of Gerrit to make it fit > better with other oVirt services. I want to share the result of this > effort. Hopefully we can gather some feedback before applying the design to > oVirt's instance of Gerrit. > > Please visit the Staging instance to check it out: > > https://gerrit-staging.phx.ovirt.org/ > > The new design is inspired by oVirt's main website. There is a known > glitch that the "Loading Gerrit Code Review" message is overlapped by the > logo when the UI is loading. If you spot any other issues or have ideas for > improvement feel free to respond to this thread or share your feedback in > the following JIRA ticket: > > https://ovirt-jira.atlassian.net/browse/OVIRT-912 > > -- > Regards, > Evgheni Dereveanchin > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Fwd: Your message to Users awaits moderator approval
I guess it would be best if you subscribe, but it isn't mandatory. CC-ing infra@ovirt.org just in case I'm missing something. On May 2, 2017 12:08 PM, "Jia Zhang" wrote: > Hi Oved: > I have posted a mail on the topic and got a mail , waiting for > verification. > Shall I do anything else to get new updates ? > > Best Regards > Kevin Zhang > GSS Pek Lab Admin > ☺: Kevin|jiazhan | ✉: jiaz...@redhat.com > > Most of your answer is here, > https://operations.cee.redhat.com/ > > -- Forwarded message -- > From: > Date: Tue, May 2, 2017 at 2:32 PM > Subject: Your message to Users awaits moderator approval > To: jiaz...@redhat.com > > > Your mail to 'Users' with the subject > > use ovirt sdk with python to query memory/cpu usage on hpyervisors > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > http://lists.ovirt.org/mailman/confirm/users/97aa6c1d1c8bcdc > 7bd5307abf4188f16d4384346 > > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] OST failure NoClassDefFoundError
I guess you need to upgrade vdsm-jsonrpc-java. Did you try that? On Tue, Apr 25, 2017 at 12:57 AM, Roy Golan wrote: > I get this on basic suite from a built RPM[1]: > > Caused by: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils > at > org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message.withCorrelationId(Message.java:75) > [vdsm-jsonrpc-java-client.jar:] > at > org.ovirt.vdsm.jsonrpc.client.reactors.stomp.SSLStompClient.sendMessage(SSLStompClient.java:85) > [vdsm-jsonrpc-java-client.jar:] > at > org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:83) > [vdsm-jsonrpc-java-client.jar:] > > > My patch under test certainly didn't touch this area [2] > > [1] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/290/ > artifact/exported-artifacts/test_logs/basic-suite-master/ > post-002_bootstrap.py/lago-basic-suite-master-engine/_ > var_log/ovirt-engine/engine.log > > [2] https://gerrit.ovirt.org/#/c/75262/ > > Did anyone see that? > > > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
can you add Lukas to the whitelist?
Patch Set 4: No Builds Executed http://jenkins.ovirt.org/job/ovirt-engine-api-model_master_check-patch-fc25-x86_64/198/ : To avoid overloading the infrastructure, a whitelist for running gerrit triggered jobs has been set in place, if you feel like you should be in it, please contact infra at ovirt dot org. Thanks, Oved ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] [ OST Failure Report ] [ ovirt-engine-4.1 ] [ 02.03.2017 ] [004_basic_sanity]
As Piotr mentioned, the job is using 1.3.8 however 1.3.9 was released. On Sun, Mar 19, 2017 at 10:27 AM, Barak Korren wrote: > > > בתאריך 17 במרץ 2017 02:32 PM, "Piotr Kliczewski" < > piotr.kliczew...@gmail.com> כתב: > > > The change was merged 2 weeks ago. How can we make sure not to waste > people time next time to analyze the issue? > > > "Merged" is hardly "released". > > As long as a fix does not make it to a release, users can still come > across the issue, and so can OST. I can't think of a quick way to avoid > that, but I'm open to suggestions > > WRT getting more frequent oVirt releases, I'm hardly in a position to give > input about that. > > > > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ OST Failure Report ] [ oVirt 4.1 ] [ 09/02/17 ] [ basic_sanity.assign_hosts_network_label ]
I do see the unrecognized message received beforehand.
I do expect [1] to fix it.
Martin - shall we merge [1] if it passed OST when you tested it?
Do we want a few additional runs?
[1] https://gerrit.ovirt.org/#/c/73745/
On Thu, Mar 9, 2017 at 3:10 PM, Oved Ourfali wrote:
> Both hosts are Up.
> When you try to add the label the host is still not up, but a few seconds
> later it moves to Up.
>
>
> On Thu, Mar 9, 2017 at 2:55 PM, Dan Kenigsberg wrote:
>
>> On Thu, Mar 9, 2017 at 1:50 PM, Daniel Belenky
>> wrote:
>> > Test failed: basic_sanity.assign_hosts_network_label
>> >
>> > Link to failed job: test-repo_ovirt_experimental_master/5754
>> >
>> > Link to all logs: logs from Jenkins
>> >
>> > Error snippet from log:
>> >
>> > lago.utils: ERROR: Error while running thread
>> > Traceback (most recent call last):
>> > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 57, in
>> > _ret_via_queue
>> > queue.put({'return': func()})
>> > File
>> > "/home/jenkins/workspace/test-repo_ovirt_experimental_master
>> /ovirt-system-tests/basic-suite-master/test-scenarios/
>> 005_network_by_label.py",
>> > line 56, in _assign_host_network_label
>> > host_nic=nic
>> > File
>> > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py",
>> line
>> > 16231, in add
>> > headers={"Correlation-Id":correlation_id, "Expect":expect}
>> > File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/
>> proxy.py",
>> > line 79, in add
>> > return self.request('POST', url, body, headers, cls=cls)
>> > File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/
>> proxy.py",
>> > line 122, in request
>> > persistent_auth=self.__persistent_auth
>> > File
>> > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/co
>> nnectionspool.py",
>> > line 79, in do_request
>> > persistent_auth)
>> > File
>> > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/co
>> nnectionspool.py",
>> > line 162, in __do_request
>> > raise errors.RequestError(response_code, response_reason,
>> response_body)
>> > RequestError:
>> > status: 409
>> > reason: Conflict
>> > detail: Cannot add Label. Operation can be performed only when Host
>> status
>> > is Maintenance, Up, NonOperational.
>>
>> Leon, could you look into this job's engine.log? I suspect that the
>> added log entry there would state that the host has fallen off to
>> non-responding. If so, I suspect a bug in the transport layer.
>> ___
>> Infra mailing list
>> Infra@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>>
>>
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
Re: [ OST Failure Report ] [ oVirt 4.1 ] [ 09/02/17 ] [ basic_sanity.assign_hosts_network_label ]
Both hosts are Up.
When you try to add the label the host is still not up, but a few seconds
later it moves to Up.
On Thu, Mar 9, 2017 at 2:55 PM, Dan Kenigsberg wrote:
> On Thu, Mar 9, 2017 at 1:50 PM, Daniel Belenky
> wrote:
> > Test failed: basic_sanity.assign_hosts_network_label
> >
> > Link to failed job: test-repo_ovirt_experimental_master/5754
> >
> > Link to all logs: logs from Jenkins
> >
> > Error snippet from log:
> >
> > lago.utils: ERROR: Error while running thread
> > Traceback (most recent call last):
> > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 57, in
> > _ret_via_queue
> > queue.put({'return': func()})
> > File
> > "/home/jenkins/workspace/test-repo_ovirt_experimental_
> master/ovirt-system-tests/basic-suite-master/test-
> scenarios/005_network_by_label.py",
> > line 56, in _assign_host_network_label
> > host_nic=nic
> > File
> > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py",
> line
> > 16231, in add
> > headers={"Correlation-Id":correlation_id, "Expect":expect}
> > File "/usr/lib/python2.7/site-packages/ovirtsdk/
> infrastructure/proxy.py",
> > line 79, in add
> > return self.request('POST', url, body, headers, cls=cls)
> > File "/usr/lib/python2.7/site-packages/ovirtsdk/
> infrastructure/proxy.py",
> > line 122, in request
> > persistent_auth=self.__persistent_auth
> > File
> > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/
> connectionspool.py",
> > line 79, in do_request
> > persistent_auth)
> > File
> > "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/
> connectionspool.py",
> > line 162, in __do_request
> > raise errors.RequestError(response_code, response_reason,
> response_body)
> > RequestError:
> > status: 409
> > reason: Conflict
> > detail: Cannot add Label. Operation can be performed only when Host
> status
> > is Maintenance, Up, NonOperational.
>
> Leon, could you look into this job's engine.log? I suspect that the
> added log entry there would state that the host has fallen off to
> non-responding. If so, I suspect a bug in the transport layer.
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
[JIRA] (OVIRT-1236) Please give user oourfali dev permissions
Oved Ourfali created OVIRT-1236: --- Summary: Please give user oourfali dev permissions Key: OVIRT-1236 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1236 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Oved Ourfali Assignee: infra Thanks, Oved -- This message was sent by Atlassian JIRA (v1000.815.1#100035) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[JIRA] (OVIRT-824) Jenkins CI not triggering for ovirt-engine-dashboard gerrit patches
[ https://ovirt-jira.atlassian.net/browse/OVIRT-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22606#comment-22606 ] Oved Ourfali commented on OVIRT-824: Adding Eyal. Thanks, Oved On Thu, Nov 10, 2016 at 9:27 PM, Scott Dickerson wrote: > Hi, > > I submitted an ovirt-engine-dashboard patch [1] last night. The > gerrit-hooks ran just fine to attach the patch to its BZ [2]. However, the > normal Jenkins CI hooks/job did not. I tried rerunning the hooks with the > "Rerun-Hooks: all" gerrit comments on the patch, but Jenkins CI did not run > again. How can we tell if the Jenkins CI triggers on the > ovirt-engine-dashboard gerrit are still configured correctly? What can be > done to fix the problem? > > To attempt to work around the issue, I tried the gerrit manual trigger > page [3]. Unfortunately my jenkins account (sdickers) does not have the > appropriate permission to the page. My teammate was able to manually > trigger the job and my patch cleared CI (thanks Greg). Who do I need to > ping to get that permission added to my account? > > Regards, > Scott > > [1] - https://gerrit.ovirt.org/66368 > [2] - https://bugzilla.redhat.com/1389382 > [3] - http://jenkins.ovirt.org/gerrit_manual_trigger/ > > -- > Scott Dickerson > Senior Software Engineer > RHEV-M Engineering - UX Team > Red Hat, Inc > > Jenkins CI not triggering for ovirt-engine-dashboard gerrit patches > --- > > Key: OVIRT-824 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-824 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL >Reporter: Scott Dickerson >Assignee: infra > > Hi, > I submitted an ovirt-engine-dashboard patch [1] last night. The > gerrit-hooks ran just fine to attach the patch to its BZ [2]. However, the > normal Jenkins CI hooks/job did not. I tried rerunning the hooks with the > "Rerun-Hooks: all" gerrit comments on the patch, but Jenkins CI did not run > again. How can we tell if the Jenkins CI triggers on the > ovirt-engine-dashboard gerrit are still configured correctly? What can be > done to fix the problem? > To attempt to work around the issue, I tried the gerrit manual trigger page > [3]. Unfortunately my jenkins account (sdickers) does not have the > appropriate permission to the page. My teammate was able to manually > trigger the job and my patch cleared CI (thanks Greg). Who do I need to > ping to get that permission added to my account? > Regards, > Scott > [1] - https://gerrit.ovirt.org/66368 > [2] - https://bugzilla.redhat.com/1389382 > [3] - http://jenkins.ovirt.org/gerrit_manual_trigger/ > -- > Scott Dickerson > Senior Software Engineer > RHEV-M Engineering - UX Team > Red Hat, Inc -- This message was sent by Atlassian JIRA (v1000.526.2#100018) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Errors / warnings in ovirt-engine-nodejs-modules build log
Seems like we're now failing on missing dependency, on libfontconfig.so.1. See http://jenkins.ovirt.org/user/sbonazzo/my-views/view/Failing%20by%20release/view/master/job/ovirt-engine-dashboard_master_build-artifacts-el7-x86_64/55/console I've added https://gerrit.ovirt.org/#/c/61817 but haven't verified it yet. Not sure how actually. Few questions: 1. Is that the right place to have this dependency, or should it be done in the dashboard package itself? 2. How can we test that end-to-end via jenkins? Thanks, Oved On Tue, Aug 2, 2016 at 9:32 AM, Sandro Bonazzola wrote: > > > On Tue, Aug 2, 2016 at 8:17 AM, Oved Ourfali wrote: > >> Eyal - see Juan's comment in his patch: >> Juan Hernandez >> 12:07 AM >> ↩ >> >> Patch Set 4: >> >> This is going to fail as well, the old .src.rpm file exists outside of >> the chroot where the build.sh script runs, so that script can't remove it. >> We definitively need help from the CI team to clean that slave. >> >> >> Can you clean it? >> > > > Done > > >> >> Thanks, >> Oved >> >> On Tue, Aug 2, 2016 at 9:06 AM, Sandro Bonazzola >> wrote: >> >>> >>> >>> On Mon, Aug 1, 2016 at 9:56 PM, Vojtech Szocs wrote: >>> >>>> >>>> >>>> - Original Message - >>>> > From: "Juan Hernández" >>>> > To: "Eyal Edri" , "Vojtech Szocs" < >>>> vsz...@redhat.com>, "Anton Marchukov" >>>> > Cc: "infra" >>>> > Sent: Monday, August 1, 2016 9:30:23 PM >>>> > Subject: Re: Errors / warnings in ovirt-engine-nodejs-modules build >>>> log >>>> > >>>> > On 08/01/2016 09:01 PM, Eyal Edri wrote: >>>> > > Anton, can you sit with Vojtech tomorrow and see if you can help? >>>> > > >>>> > > Vojtech >>>> > > Maybe we're hitting: http://rpm.org/ticket/862 >>>> > > https://bugzilla.redhat.com/show_bug.cgi?id=913099 >>>> > > >>>> > > Anyway, what I meant was to try and run it on el7 slaves, not el7 >>>> mock, >>>> > > to see if its a regression on mock running on fc24. >>>> > > trying it here to see if it >>>> > > works: >>>> > > >>>> http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-el7-x86_64_created/22/console >>>> > > >>>> > >>>> > As this seems to be a RPM limitation, and one that isn't going to be >>>> > fixed soon, I'd suggest to change the Node.js modules RPM so that it >>>> > packages a single .tar file containing all the modules. It can then, >>>> > during installation (in the %post) section extract the content to >>>> > /var/lib/ovirt-engine-nodejs-modules, so users only have to change the >>>> > directory they use. Actually, as Vojtech introduced a "setup-env.sh" >>>> > script that does all the preparations, only this script needs to be >>>> > changed. This patch reflects my suggestion: >>>> > >>>> > Package tarball containing Node.js modules >>>> > https://gerrit.ovirt.org/61790 >>>> >>>> +1 this is great! >>>> >>>> Proposed solution doesn't require any change in Dashboard code. >>>> >>>> Seems like it was only a matter of time till we hit that ~100k >>>> files limit when creating ovirt-engine-nodejs-modules RPM. >>>> >>> >>> You may also consider spliitng the rpm in subpackages in a per-module >>> fashion. >>> >>> >>> >>>> >>>> Juan++ >>>> >>>> > >>>> > > On Mon, Aug 1, 2016 at 9:42 PM, Vojtech Szocs >>> > > <mailto:vsz...@redhat.com>> wrote: >>>> > > >>>> > > >>>> > > >>>> > > - Original Message - >>>> > > > From: "Eyal Edri" mailto:ee...@redhat.com >>>> >> >>>> > > > To: "Vojtech Szocs" >>> vsz...@redhat.com>> >>>> > > > Cc: "infra" mailto:infra@ovirt.org>> >>>> > > > Sent: Monday, August 1, 2016 8:25:50 PM >>>> > > > Subject: Re: Errors / warnings in ovirt-eng
Re: Errors / warnings in ovirt-engine-nodejs-modules build log
Eyal - see Juan's comment in his patch: Juan Hernandez 12:07 AM ↩ Patch Set 4: This is going to fail as well, the old .src.rpm file exists outside of the chroot where the build.sh script runs, so that script can't remove it. We definitively need help from the CI team to clean that slave. Can you clean it? Thanks, Oved On Tue, Aug 2, 2016 at 9:06 AM, Sandro Bonazzola wrote: > > > On Mon, Aug 1, 2016 at 9:56 PM, Vojtech Szocs wrote: > >> >> >> - Original Message - >> > From: "Juan Hernández" >> > To: "Eyal Edri" , "Vojtech Szocs" , >> "Anton Marchukov" >> > Cc: "infra" >> > Sent: Monday, August 1, 2016 9:30:23 PM >> > Subject: Re: Errors / warnings in ovirt-engine-nodejs-modules build log >> > >> > On 08/01/2016 09:01 PM, Eyal Edri wrote: >> > > Anton, can you sit with Vojtech tomorrow and see if you can help? >> > > >> > > Vojtech >> > > Maybe we're hitting: http://rpm.org/ticket/862 >> > > https://bugzilla.redhat.com/show_bug.cgi?id=913099 >> > > >> > > Anyway, what I meant was to try and run it on el7 slaves, not el7 >> mock, >> > > to see if its a regression on mock running on fc24. >> > > trying it here to see if it >> > > works: >> > > >> http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-el7-x86_64_created/22/console >> > > >> > >> > As this seems to be a RPM limitation, and one that isn't going to be >> > fixed soon, I'd suggest to change the Node.js modules RPM so that it >> > packages a single .tar file containing all the modules. It can then, >> > during installation (in the %post) section extract the content to >> > /var/lib/ovirt-engine-nodejs-modules, so users only have to change the >> > directory they use. Actually, as Vojtech introduced a "setup-env.sh" >> > script that does all the preparations, only this script needs to be >> > changed. This patch reflects my suggestion: >> > >> > Package tarball containing Node.js modules >> > https://gerrit.ovirt.org/61790 >> >> +1 this is great! >> >> Proposed solution doesn't require any change in Dashboard code. >> >> Seems like it was only a matter of time till we hit that ~100k >> files limit when creating ovirt-engine-nodejs-modules RPM. >> > > You may also consider spliitng the rpm in subpackages in a per-module > fashion. > > > >> >> Juan++ >> >> > >> > > On Mon, Aug 1, 2016 at 9:42 PM, Vojtech Szocs > > > <mailto:vsz...@redhat.com>> wrote: >> > > >> > > >> > > >> > > - Original Message - >> > > > From: "Eyal Edri" mailto:ee...@redhat.com>> >> > > > To: "Vojtech Szocs" > vsz...@redhat.com>> >> > > > Cc: "infra" mailto:infra@ovirt.org>> >> > > > Sent: Monday, August 1, 2016 8:25:50 PM >> > > > Subject: Re: Errors / warnings in ovirt-engine-nodejs-modules >> build >> > > > log >> > > > >> > > > Does it work on el7? >> > > >> > > It fails on el7 as well: >> > > >> > > >> http://jenkins.ovirt.org/job/ovirt-engine-nodejs-modules_master_create-rpms-el7-x86_64_created/21/console >> > > >> > > error: Unable to create immutable header region. >> > > >> > > > >> > > > On Mon, Aug 1, 2016 at 8:21 PM, Vojtech Szocs < >> vsz...@redhat.com >> > > <mailto:vsz...@redhat.com>> wrote: >> > > > >> > > > > Forwarding to infra, TL;DR we seem to have an issue with >> rpmbuild >> > > > > (see below) and I'm not sure how to fix that, is there anyone >> who >> > > > > faced such issue in past? >> > > > > >> > > > > Vojtech >> > > > > >> > > > > >> > > > > - Forwarded Message - >> > > > > From: "Vojtech Szocs" > > > > > <mailto:vsz...@redhat.com>> >> > > > > To: "Sandro Bonazzola" > > > <mailto:sbona...@redhat.com>> >> > > > > Cc: "Oved Ourfali" > > > &
Can't login to gerrit
I'm using the "Google OAuth2 (gerrit-oauth-provider plugin)" option and I get "Server Error". Happened also to someone in my team. Can you take a look? Thanks, Oved ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: vdsm-jsonrpc-java_{master,3.6}_build-artifacts-fc23 Failure
So what do you suggest to do? Just wait for a release fixing it by the openjdk guys? I guess it depends on when can we expect such a release to take place. On Apr 25, 2016 21:57, "Yaniv Kaul" wrote: > > Since this Java update solves several CVEs, I don't see how we can roll back. > Y. > > On Mon, Apr 25, 2016 at 9:43 PM, Piotr Kliczewski wrote: >> >> I pushed [1] patch to keep specific version of java but I see jenkins complaining about it: >> >> Package matching 1:java-1.8.0-openjdk-devel-1.8.0.60-14.b27.fc23.x86_64 already installed. Checking for update. >> >> and later: >> >> 18:39:15 error: Failed build dependencies: >> 18:39:15 java-1.8.0-openjdk-devel = 1:1.8.0.60 is needed by vdsm-jsonrpc-java-1.2.2-master.fc23.noarch >> >> >> >> [1] https://gerrit.ovirt.org/#/c/56583 >> >> On Mon, Apr 25, 2016 at 8:15 PM, Piotr Kliczewski wrote: >>> >>> I downgraded to java-1.8.0-openjdk-1.8.0.60-14.b27 and it works again. >>> >>> We need to make sure that we update you spec files. >>> >>> On Mon, Apr 25, 2016 at 7:46 PM, Piotr Kliczewski wrote: I looks like it was already reported [1]. [1] https://bugzilla.redhat.com/1329342 On Mon, Apr 25, 2016 at 7:42 PM, Piotr Kliczewski wrote: > > It is interesting to see that ssl communication stopped working on CI only for f23. > > I have tested it for some time and was not able to reproduce the issue. > > After a while I noticed that there are some updates including java. > > In between my tests I updated my system (f23) and first attempt reproduced the issue. > > One of the packages being updated: > > java-1.8.0-openjdk.x86_64 1:1.8.0.91-1.b14.fc23 > > Investigating what changes were introduced in this version. > > As workaround we can downgrade java before I will find a fix. > > Thanks, > Piotr > > On Mon, Apr 25, 2016 at 3:03 PM, Nadav Goldin wrote: >> >> Hey Piotr and Oved, >> Can you have a look at: >> http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_master_build-artifacts-fc23-x86_64/3/console >> http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_3.6_build-artifacts-fc23-x86_64/1/console >> >>> >> 07:02:35 Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 560.634 sec <<< FAILURE! - in org.ovirt.vdsm.jsonrpc.client.reactors.stomp.SSLStompClientTestCase >>> >> 07:02:35 testLongMessage(org.ovirt.vdsm.jsonrpc.client.reactors.stomp.SSLStompClientTestCase) Time elapsed: 180.56 sec <<< ERROR! >>> >> 07:02:35 org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection timeout >> >> >> to ensure this isn't related to the Jenkins migration I re-triggered it on the old instance with the same results( http://jenkins-old.ovirt.org/job/vdsm-jsonrpc-java_master_build-artifacts-fc23-x86_64/14/ ) >> >> Thanks, >> >> Nadav. >> > >>> >> > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Old patches
+1. On Mon, Sep 7, 2015 at 12:08 PM, Piotr Kliczewski < piotr.kliczew...@gmail.com> wrote: > Can you please ack my request? > > Thanks, > Piotr > > On Mon, Sep 7, 2015 at 10:48 AM, Piotr Kliczewski > wrote: > > There are few patches [1] by Saggi which can be abandoned from both > > vdsm and engine. > > I need a permission to do it so please assigned it to me. > > > > Thanks, > > Piotr > > > > > > [1] > https://gerrit.ovirt.org/#/q/owner:smizrahi%2540redhat.com+status:open > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] gerrit+ci improvement proposal
On Jun 7, 2015 10:00 AM, Eyal Edri wrote: > > > > - Original Message - > > From: "Oved Ourfali" > > To: "Eyal Edri" > > Cc: infra@ovirt.org, de...@ovirt.org > > Sent: Sunday, June 7, 2015 9:55:56 AM > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > - Original Message - > > > From: "Eyal Edri" > > > To: "Eli Mesika" > > > Cc: "Oved Ourfali" , de...@ovirt.org, infra@ovirt.org > > > Sent: Sunday, June 7, 2015 9:52:15 AM > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > - Original Message - > > > > From: "Eli Mesika" > > > > To: "Oved Ourfali" > > > > Cc: "Eyal Edri" , infra@ovirt.org, de...@ovirt.org > > > > Sent: Thursday, June 4, 2015 3:49:05 PM > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Oved Ourfali" > > > > > To: "Eyal Edri" > > > > > Cc: de...@ovirt.org, infra@ovirt.org > > > > > Sent: Thursday, June 4, 2015 10:03:02 AM > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Eyal Edri" > > > > > > To: "Sandro Bonazzola" > > > > > > Cc: infra@ovirt.org, de...@ovirt.org > > > > > > Sent: Thursday, June 4, 2015 9:46:40 AM > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "Sandro Bonazzola" > > > > > > > To: "Eyal Edri" , "Max Kovgan" > > > > > > > > > > > > > > Cc: de...@ovirt.org, infra@ovirt.org > > > > > > > Sent: Thursday, June 4, 2015 9:11:10 AM > > > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > Il 03/06/2015 21:46, Eyal Edri ha scritto: > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > >> From: "Max Kovgan" > > > > > > > >> To: de...@ovirt.org > > > > > > > >> Cc: infra@ovirt.org > > > > > > > >> Sent: Wednesday, June 3, 2015 8:22:54 PM > > > > > > > >> Subject: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > >> > > > > > > > >> Hi everyone! > > > > > > > >> We really want to have reliable and snappy CI: to allow short > > > > > > > >> cycles > > > > > > > >> and > > > > > > > >> encourage developers to write tests. > > > > > > > >> > > > > > > > >> # Problem > > > > > > > >> > > > > > > > >> Many patches are neither ready for review nor for CI upon > > > > > > > >> submission, > > > > > > > >> which > > > > > > > >> is OK. > > > > > > > >> But running all the jobs on those patches with limited > > > > > > > >> resources > > > > > > > >> results > > > > > > > >> in: > > > > > > > >> overloaded resources, slow response time, unhappy developers. > > > > > > > >> > > > > > > > >> # Proposed Solution > > > > > > > >> > > > > > > > >> To run less jobs we know we don’t need to, thus making more > > > > > > > >> resources > > > > > > > >> for > > > > > > > >> the > > > > > > > >> jobs we need to run. > > > > > >
Re: [ovirt-devel] gerrit+ci improvement proposal
- Original Message - > From: "Eyal Edri" > To: "Eli Mesika" > Cc: "Oved Ourfali" , de...@ovirt.org, infra@ovirt.org > Sent: Sunday, June 7, 2015 9:52:15 AM > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > - Original Message - > > From: "Eli Mesika" > > To: "Oved Ourfali" > > Cc: "Eyal Edri" , infra@ovirt.org, de...@ovirt.org > > Sent: Thursday, June 4, 2015 3:49:05 PM > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "Eyal Edri" > > > Cc: de...@ovirt.org, infra@ovirt.org > > > Sent: Thursday, June 4, 2015 10:03:02 AM > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > - Original Message - > > > > From: "Eyal Edri" > > > > To: "Sandro Bonazzola" > > > > Cc: infra@ovirt.org, de...@ovirt.org > > > > Sent: Thursday, June 4, 2015 9:46:40 AM > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Sandro Bonazzola" > > > > > To: "Eyal Edri" , "Max Kovgan" > > > > > Cc: de...@ovirt.org, infra@ovirt.org > > > > > Sent: Thursday, June 4, 2015 9:11:10 AM > > > > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > > > > > > > Il 03/06/2015 21:46, Eyal Edri ha scritto: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > >> From: "Max Kovgan" > > > > > >> To: de...@ovirt.org > > > > > >> Cc: infra@ovirt.org > > > > > >> Sent: Wednesday, June 3, 2015 8:22:54 PM > > > > > >> Subject: [ovirt-devel] gerrit+ci improvement proposal > > > > > >> > > > > > >> Hi everyone! > > > > > >> We really want to have reliable and snappy CI: to allow short > > > > > >> cycles > > > > > >> and > > > > > >> encourage developers to write tests. > > > > > >> > > > > > >> # Problem > > > > > >> > > > > > >> Many patches are neither ready for review nor for CI upon > > > > > >> submission, > > > > > >> which > > > > > >> is OK. > > > > > >> But running all the jobs on those patches with limited resources > > > > > >> results > > > > > >> in: > > > > > >> overloaded resources, slow response time, unhappy developers. > > > > > >> > > > > > >> # Proposed Solution > > > > > >> > > > > > >> To run less jobs we know we don’t need to, thus making more > > > > > >> resources > > > > > >> for > > > > > >> the > > > > > >> jobs we need to run. > > > > > >> We have been experimenting to make our CI stabler and quicker to > > > > > >> respond > > > > > >> by > > > > > >> using gerrit flags. This has improved in both directions very well > > > > > >> internally. > > > > > >> Now it seems a good time to let all the oVirt projects to use > > > > > >> this. > > > > > >> This solution indirectly promotes reviews and quick tests - “to > > > > > >> fail > > > > > >> early”, > > > > > >> yet full blown static code analysis and long tests to run “when > > > > > >> ready”. > > > > > >> > > > > > >> # How it works > > > > > >> > > > > > >> 2 new gerrit independent flags are added to gerrit. > > > > > >> > > > > > >> ## CI flag > > > > > >> > > > > > >> Will express patch CI status. Values: > > > > > >> * +1 CI passed > > > > > >> * 0 CI did not run yet > > > > > >> * -1 CI failed > >
Re: [ovirt-devel] gerrit+ci improvement proposal
- Original Message - > From: "Eyal Edri" > To: "Sandro Bonazzola" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Thursday, June 4, 2015 9:46:40 AM > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > - Original Message - > > From: "Sandro Bonazzola" > > To: "Eyal Edri" , "Max Kovgan" > > Cc: de...@ovirt.org, infra@ovirt.org > > Sent: Thursday, June 4, 2015 9:11:10 AM > > Subject: Re: [ovirt-devel] gerrit+ci improvement proposal > > > > Il 03/06/2015 21:46, Eyal Edri ha scritto: > > > > > > > > > - Original Message - > > >> From: "Max Kovgan" > > >> To: de...@ovirt.org > > >> Cc: infra@ovirt.org > > >> Sent: Wednesday, June 3, 2015 8:22:54 PM > > >> Subject: [ovirt-devel] gerrit+ci improvement proposal > > >> > > >> Hi everyone! > > >> We really want to have reliable and snappy CI: to allow short cycles and > > >> encourage developers to write tests. > > >> > > >> # Problem > > >> > > >> Many patches are neither ready for review nor for CI upon submission, > > >> which > > >> is OK. > > >> But running all the jobs on those patches with limited resources results > > >> in: > > >> overloaded resources, slow response time, unhappy developers. > > >> > > >> # Proposed Solution > > >> > > >> To run less jobs we know we don’t need to, thus making more resources > > >> for > > >> the > > >> jobs we need to run. > > >> We have been experimenting to make our CI stabler and quicker to respond > > >> by > > >> using gerrit flags. This has improved in both directions very well > > >> internally. > > >> Now it seems a good time to let all the oVirt projects to use this. > > >> This solution indirectly promotes reviews and quick tests - “to fail > > >> early”, > > >> yet full blown static code analysis and long tests to run “when ready”. > > >> > > >> # How it works > > >> > > >> 2 new gerrit independent flags are added to gerrit. > > >> > > >> ## CI flag > > >> > > >> Will express patch CI status. Values: > > >> * +1 CI passed > > >> * 0 CI did not run yet > > >> * -1 CI failed > > >> Permissions for setting: project maintainers (for special cases) should > > >> be > > >> able to set/override (except Jenkins). > > >> > > >> ## Workflow flag > > >> > > >> Will express patch “workflow” state. Values: > > >> * 0 Work In Progress > > >> * +1 Ready For Review > > >> * +2 Ready For Merge > > >> Permissions for setting: Owner can set +1, Project Maintainers can set > > >> +2 > > >> > > >> ## Review + CI Integration: > > >> > > >> Merging [“Submit” button to appear] will require: Review+1, CI+1, > > >> Workflow+2 > > >> Patch lifecycle now is: > > >> --- > > >> patch state |owner |reviewer |maintainer |CI tests |pass > > >> --- > > >> added/updated |- |-|- |quick|CI+1 > > >> review|Workflow+1|Review+1 |- |heavy |CI+1 > > >> merge ready |- |-|Workflow+2 |gating |CI+1 > > >> merge |- |-|merge |merge|CI+1 > > >> > > >> Changes from current workflow: > > >> Owner only adds reviewers, now owner needs to set "Workflow+1" for the > > >> patch > > >> to be reviewed, and heavily auto-tested. > > >> Maintainer now needs to set "Workflow+2" and wait for "Submit" button to > > >> appear after CI has completed running gating tests. > > >> > > >> > > >> Next step will be to automate merge the change after Workflow+2 has been > > >> set > > >> by the Maintainer and gating tests passed. > > >> > > >> > > >> ## Why now? > > >> > > >> It is elimination of waste. The sooner - the better. > > >> The solution has been used for a while and it works. > > >> Resolving the problem without gerrit involved will lead to adding > > >> unreliable > > >> code into jobs, and will still be prone to problems: > > >> Just recently, 3d ago we’ve tried detecting what to run from jenkins > > >> relying only on gerrit comments so that upon Verified+1, we’d run the > > >> job. > > >> We could not use “Review+1”, because it makes no sense at all, so we > > >> left > > >> the job to set Verified+1. > > >> Meaning - re-trigger itself immediately more than 1 times. > > >> > > >> Jenkins and its visitors very unhappy, and we had to stop those jobs, > > >> clean > > >> up the queue, and spam developers. > > >> > > >> ## OK OK OK. Now what? > > >> > > >> Now we want your comments and opinions before pushing this further: > > >> Please participate in this thread, so we can start trying it out. > > >> Ask, Suggest better ideas, all this is welcome. > > >> > > >> > > >> Best Regards! > > >> > > >> > > >> N.B. > > >> Of course, this is not written in stone, in case we find a better > > >> approach > > >> on > > >> solving those issues, we will change to it. > > >> And we will keep improving so don't be afraid that it will be enforced: > > >> if > > >> this does not work o
link fedora account ovedo to oved...@gmail.com
Hi Can you please link my fedora account (ovedo) to my current gerrit acount email (oved...@gmail.com)? Thanks, Oved ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
gerrit.ovirt.org is inaccessible
Hi When trying to access gerrit.ovirt.org, I get "Service Temporarily Unavailable". Can someone check that out? Thanks, Oved ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) to Cluster 3.6
On Feb 11, 2015 10:49 PM, Michael Burman wrote:
>
> Hello Yaniv and all!
>
> So i did this:
> I tried to install clean rhel7.1 host with the right libvirt
> version(libvirt-1.2.8-16.el7.x86_64,vdsm-4.17.0-394.gitb237397.el7.x86_64)
> and failed to join this host under 3.6 cluster.
> Host red-vds2.qa.lab.tlv.redhat.com is compatible with versions
> (3.0,3.1,3.2,3.3,3.4,3.5) and cannot join Cluster mb3.6 which is set to
> version 3.6.
> After failing i checked the /usr/share/vdsm/dsaversion.py and saw that:
> version_info = {
> 'version_name': version_name,
> 'software_version': software_version,
> 'software_revision': software_revision,
> 'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5'],
> 'supportedProtocols': ['2.2', '2.3'],
> 'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5'],
>
> So i added the 3.6 for cluster levels and engine support lines, restarted
> vdsm and finally managed to join my rhel7.1 host to 3.6 Cluster.
>
> All of this means that rhel7.1 hosts with vdsm 4.17.0 and libvirt version
> -libvirt-1.2.8-16.el7.x86_64 are still not supported by default for 3.6
> clusters and dsaversion.py file must be edited manually in order to join to
> cluster 3.6.
> I guess this must be changed.
>
+1 on that one.
> Best regards,
> Michael B
>
>
> - Original Message -
> From: "Michael Burman"
> To: "ybronhei"
> Cc: de...@ovirt.org, infra@ovirt.org
> Sent: Monday, February 9, 2015 10:50:28 AM
> Subject: Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64)
> to Cluster 3.6
>
> Thank you all!
>
> Ok, so how can i get this right libvirt version for rhel7? not7.1 and without
> any dependencies issues??
> I want to join rhel7 host, with the right libvirt version to 3.6 cluster..is
> it possible?
>
> Michael B
>
>
> - Original Message -
> From: "ybronhei"
> To: "Oved Ourfali" , "Sandro Bonazzola"
> , "Dan Kenigsberg"
> Cc: infra@ovirt.org, de...@ovirt.org, "Michael Burman"
> Sent: Monday, February 9, 2015 10:03:56 AM
> Subject: Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64)
> to Cluster 3.6
>
> On 02/09/2015 08:35 AM, Oved Ourfali wrote:
> >
> > On Feb 9, 2015 9:31 AM, Sandro Bonazzola wrote:
> >>
> >> Il 08/02/2015 16:15, Michael Burman ha scritto:
> >>> Hi everyone!
> >>>
> >>> Is any one knows when it will be possible to join vdsm-4.17.0 to 3.6
> >>> Cluster??
> >>> I know that the libvirt version is not supported, but isn't should be?
> >>> even if it's rhel7..?
> >>>
> >>> I changed the /usr/share/vdsm/dsaversion.py file to:
> >>> 'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],
> >>> 'supportedProtocols': ['2.2', '2.3'],
> >>> 'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],
> >>>
> >>> But caps.py is still:
> >>> if not hasattr(libvirt, 'VIR_MIGRATE_AUTO_CONVERGE'):
> >>> return _dropVersion('3.6',
> >>> 'VIR_MIGRATE_AUTO_CONVERGE not found in
> >>>libvirt,'
> >>> ' support for clusterLevel >= 3.6 is
> >>>disabled.'
> >>> ' For Fedora 20 users, please consider
> >>>upgrading'
> >>> ' libvirt from the virt-preview
> >>>repository')
> >>>
> >>> if not hasattr(libvirt, 'VIR_MIGRATE_COMPRESSED'):
> >>> return _dropVersion('3.6',
> >>> 'VIR_MIGRATE_COMPRESSED not found in
> >>>libvirt,'
> >>> ' support for clusterLevel >= 3.6 is
> >>>disabled.'
> >>> ' For Fedora 20 users, please consider
> >>>upgrading'
> >>> ' libvirt fr
Re: [ovirt-devel] Can't join vdsm(4.17.0-390.gita3163f3.el7.x86_64) to Cluster 3.6
On Feb 9, 2015 9:31 AM, Sandro Bonazzola wrote:
>
> Il 08/02/2015 16:15, Michael Burman ha scritto:
> > Hi everyone!
> >
> > Is any one knows when it will be possible to join vdsm-4.17.0 to 3.6
> > Cluster??
> > I know that the libvirt version is not supported, but isn't should be? even
> > if it's rhel7..?
> >
> > I changed the /usr/share/vdsm/dsaversion.py file to:
> > 'supportedENGINEs': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],
> > 'supportedProtocols': ['2.2', '2.3'],
> > 'clusterLevels': ['3.0', '3.1', '3.2', '3.3', '3.4', '3.5', '3.6'],
> >
> > But caps.py is still:
> > if not hasattr(libvirt, 'VIR_MIGRATE_AUTO_CONVERGE'):
> > return _dropVersion('3.6',
> > 'VIR_MIGRATE_AUTO_CONVERGE not found in
> >libvirt,'
> > ' support for clusterLevel >= 3.6 is disabled.'
> > ' For Fedora 20 users, please consider
> >upgrading'
> > ' libvirt from the virt-preview repository')
> >
> > if not hasattr(libvirt, 'VIR_MIGRATE_COMPRESSED'):
> > return _dropVersion('3.6',
> > 'VIR_MIGRATE_COMPRESSED not found in libvirt,'
> > ' support for clusterLevel >= 3.6 is disabled.'
> > ' For Fedora 20 users, please consider
> >upgrading'
> > ' libvirt from the virt-preview repository')
> >
> > libvirt is still disabled for 3.6 clusters...
> >
> >
> > I already tried to rebuild from fedora(with Sandro appreciated help), but
> > had a lot of issues dependencies.
> >
> > I'm running on-
> > ovirt-engine-3.6.0-0.0.master.20150206122208.gitd429375.el6.noarch
> > vdsm-4.17.0-390.gita3163f3.el7.x86_64
> > libvirt-1.1.1-29.el7_0.7.x86_64
> >
> > I would like to know if and when it will be possible to join rhel7
> > host(vdsm-4.17.0) to Cluster 3.6?
>
> Moving to devel list, not really an infra issue.
>
Yaniv, you had a patch for that, but it was abandoned. Why?
> >
> > Best regards,
> >
> > Michael B
> >
> >
> >
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
Re: jenkins jobs on ovirt-engine-3.5 branch upstream
Yes. Thanks. - Original Message - > From: "David Caro" > To: "Oved Ourfali" > Cc: "Eyal Edri" , "Piotr Kliczewski" , > "infra" > Sent: Monday, January 26, 2015 9:33:26 PM > Subject: Re: jenkins jobs on ovirt-engine-3.5 branch upstream > > > This is already solved right? > > On 01/26, Oved Ourfali wrote: > > Yes. > > > > > > - Original Message - > > > From: "Eyal Edri" > > > To: "Oved Ourfali" > > > Cc: dc...@redhat.com, "Piotr Kliczewski" , "infra" > > > > > > Sent: Monday, January 26, 2015 1:57:41 PM > > > Subject: Re: jenkins jobs on ovirt-engine-3.5 branch upstream > > > > > > how are you trying to run it? > > > via the manual trigger job? > > > > > > also, adding infra list. > > > > > > e. > > > > > > - Original Message - > > > > From: "Oved Ourfali" > > > > To: ee...@redhat.com, dc...@redhat.com > > > > Cc: "Piotr Kliczewski" > > > > Sent: Monday, January 26, 2015 1:27:38 PM > > > > Subject: jenkins jobs on ovirt-engine-3.5 branch upstream > > > > > > > > Hi > > > > > > > > I'm trying to run the job on http://gerrit.ovirt.org/#/c/37268/ but > > > > nothing > > > > is triggered. > > > > Any known issue? can you help? > > > > > > > > Thanks, > > > > Oved > > > > > > > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: jenkins jobs on ovirt-engine-3.5 branch upstream
Yes. - Original Message - > From: "Eyal Edri" > To: "Oved Ourfali" > Cc: dc...@redhat.com, "Piotr Kliczewski" , "infra" > > Sent: Monday, January 26, 2015 1:57:41 PM > Subject: Re: jenkins jobs on ovirt-engine-3.5 branch upstream > > how are you trying to run it? > via the manual trigger job? > > also, adding infra list. > > e. > > - Original Message - > > From: "Oved Ourfali" > > To: ee...@redhat.com, dc...@redhat.com > > Cc: "Piotr Kliczewski" > > Sent: Monday, January 26, 2015 1:27:38 PM > > Subject: jenkins jobs on ovirt-engine-3.5 branch upstream > > > > Hi > > > > I'm trying to run the job on http://gerrit.ovirt.org/#/c/37268/ but > > nothing > > is triggered. > > Any known issue? can you help? > > > > Thanks, > > Oved > > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Proposing Liron Aravot as an engine-core maintainer
- Original Message - > From: "Tal Nisan" > To: "Itamar Heim" , "Livnat Peer" , "Omer > Frenkel" , "Doron > Fediuck" , "Yair Zaslavsky" , "Maor > Lipchuk" , "Roy > Golan" , "Eli Mesika" , "Mike > Kolesnik" , "Moti Asayag" > , "Shahar Havivi" , ov...@redhat.com, > "Allon Mureinik" > Cc: "engine-devel" , infra@ovirt.org > Sent: Sunday, January 26, 2014 2:47:30 PM > Subject: Proposing Liron Aravot as an engine-core maintainer > > Hi core maintainers, > > I would like to propose Liron Aravot as an engine-core maintainer. > > Liron joined the oVirt project on June 2012, and has since contributed > over 170 patches to master (not counting backports to various stable > branches). > > He has been instrumental in implementing oVirt's Backup API for external > providers, and has a been a driving force in improving flows regarding > SPM election and master domain reconstruction, handling OVF backups and > various concurrency issues both as a coder and a reviewer. > > Your response would be appreciated. > +1! > Thanks, > Tal. > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "David Caro" > To: "Yaniv Dary" > Cc: "Oved Ourfali" , de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 2:40:43 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > On 12/09, Yaniv Dary wrote: > > > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "David Caro" > > > Cc: infra@ovirt.org, de...@ovirt.org > > > Sent: Tuesday, December 9, 2014 2:27:14 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > top posting: > > > How about the following flow: > > > 1. You push a patch to gerrit. > > > 2. You need +1 on Testing in order to merge it. > > > 3. You have +1/-1 on the Tests if finished successfully/failed > > > 4. You find out you need to rebase. > > > 5. The rebase copies the result of the Tests of the previous patch-set... > > > if > > > it was +1, it remains +1 and you can merge (assuming you have +2 on CR). > > > If > > > it was -1 then you need to wait for the CI to finish, and it might set it > > > to > > > +1. > > > > > > Does that make sense? > > > > Yes, but only if you used rebase button and automatic rebase worked. > > In case of merge conflict you will need to wait after rebase for tests. > > Well, that's more or less what's happening today, we did set up the > flag propagation on trivial rebase time ago. I'll have to check how to > make jenkins ignore those trivial rebases only if they have a +1. > > So are you sure that having no merge conflict means that the rebase > patch works as before? (I imagine for example that you could have two > features that together might not work well, even if they do not touch > the same code) > > You minimize the probability that something will get wrong. It isn't 100%. Using Zuul is the right way to go, but until you have that I think what I proposed will make it both easy to use and maintain, and both safe up to 95% or so. > > > > > > > > > - Original Message - > > > > From: "Oved Ourfali" > > > > To: "David Caro" > > > > Cc: de...@ovirt.org, infra@ovirt.org > > > > Sent: Tuesday, December 9, 2014 1:13:57 PM > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "David Caro" > > > > > To: "Oved Ourfali" > > > > > Cc: infra@ovirt.org, de...@ovirt.org > > > > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > On 12/09, Oved Ourfali wrote: > > > > > > What happens when rebasing? > > > > > > We can't afford waiting for tests to run on each rebase... as we > > > > > > might > > > > > > end > > > > > > up rebasing forever. > > > > > > > > > > For now we will have to, all the code that is going to be merged must > > > > > be tested as it is going to be merged, that means running the tests > > > > > in > > > > > the last rebase too. > > > > > > > > > > In the future there are plans on using a gating system like zuul, so > > > > > zuul will be the one monitoring the tests and merging when passes, so > > > > > you will just add the flag, and that will trigger the gate, that runs > > > > > the tests and merged the patch. > > > > > > > > > > It's unlikely that you'll have to wait forever, but there's nothing > > > > > avoiding you doing that (right now even). > > > > > > > > > > I'd like to put emphasis again on differentiating between tests that > > > > > are fast, that should run on each patch and tests that are slow, that > > > > > should run on each merge. That will improve the feedback times. > > > > > > > > > > > > > So let's apply that in the future. > > > > For now the amount of merges done is enormous, and it will be > > > > impossible to > > > > get things merged on a reasonable time. > > > > Again, I'm not against testing, but it should be done the right way... > >
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Yaniv Dary" > To: "Oved Ourfali" > Cc: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 2:29:38 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > - Original Message - > > From: "Oved Ourfali" > > To: "David Caro" > > Cc: infra@ovirt.org, de...@ovirt.org > > Sent: Tuesday, December 9, 2014 2:27:14 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > top posting: > > How about the following flow: > > 1. You push a patch to gerrit. > > 2. You need +1 on Testing in order to merge it. > > 3. You have +1/-1 on the Tests if finished successfully/failed > > 4. You find out you need to rebase. > > 5. The rebase copies the result of the Tests of the previous patch-set... > > if > > it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If > > it was -1 then you need to wait for the CI to finish, and it might set it > > to > > +1. > > > > Does that make sense? > > Yes, but only if you used rebase button and automatic rebase worked. > In case of merge conflict you will need to wait after rebase for tests. > In such cases I think the reviewer should compare and decide, rather than wait for tests to finish. > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "David Caro" > > > Cc: de...@ovirt.org, infra@ovirt.org > > > Sent: Tuesday, December 9, 2014 1:13:57 PM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: "Oved Ourfali" > > > > Cc: infra@ovirt.org, de...@ovirt.org > > > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > On 12/09, Oved Ourfali wrote: > > > > > What happens when rebasing? > > > > > We can't afford waiting for tests to run on each rebase... as we > > > > > might > > > > > end > > > > > up rebasing forever. > > > > > > > > For now we will have to, all the code that is going to be merged must > > > > be tested as it is going to be merged, that means running the tests in > > > > the last rebase too. > > > > > > > > In the future there are plans on using a gating system like zuul, so > > > > zuul will be the one monitoring the tests and merging when passes, so > > > > you will just add the flag, and that will trigger the gate, that runs > > > > the tests and merged the patch. > > > > > > > > It's unlikely that you'll have to wait forever, but there's nothing > > > > avoiding you doing that (right now even). > > > > > > > > I'd like to put emphasis again on differentiating between tests that > > > > are fast, that should run on each patch and tests that are slow, that > > > > should run on each merge. That will improve the feedback times. > > > > > > > > > > So let's apply that in the future. > > > For now the amount of merges done is enormous, and it will be impossible > > > to > > > get things merged on a reasonable time. > > > Again, I'm not against testing, but it should be done the right way... > > > > > > > > > > > > > - Original Message - > > > > > > From: "David Caro" > > > > > > To: de...@ovirt.org, infra@ovirt.org > > > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > > > > > Hi! > > > > > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > > > propose creating a new gerrit flag (Tests) with the following > > > > > > specifics: > > > > > > > > > > > > > > > > > > +1 - Tests passed/overrided > > > > > > 0 - Tests pending > > > > > > -1 - Tests broken > > > > > > > > > > > > where +1 is required to submit,
Re: [ovirt-devel] Creating a new gerrit flag
top posting: How about the following flow: 1. You push a patch to gerrit. 2. You need +1 on Testing in order to merge it. 3. You have +1/-1 on the Tests if finished successfully/failed 4. You find out you need to rebase. 5. The rebase copies the result of the Tests of the previous patch-set... if it was +1, it remains +1 and you can merge (assuming you have +2 on CR). If it was -1 then you need to wait for the CI to finish, and it might set it to +1. Does that make sense? - Original Message - > From: "Oved Ourfali" > To: "David Caro" > Cc: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 1:13:57 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > - Original Message - > > From: "David Caro" > > To: "Oved Ourfali" > > Cc: infra@ovirt.org, de...@ovirt.org > > Sent: Tuesday, December 9, 2014 12:12:19 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > On 12/09, Oved Ourfali wrote: > > > What happens when rebasing? > > > We can't afford waiting for tests to run on each rebase... as we might > > > end > > > up rebasing forever. > > > > For now we will have to, all the code that is going to be merged must > > be tested as it is going to be merged, that means running the tests in > > the last rebase too. > > > > In the future there are plans on using a gating system like zuul, so > > zuul will be the one monitoring the tests and merging when passes, so > > you will just add the flag, and that will trigger the gate, that runs > > the tests and merged the patch. > > > > It's unlikely that you'll have to wait forever, but there's nothing > > avoiding you doing that (right now even). > > > > I'd like to put emphasis again on differentiating between tests that > > are fast, that should run on each patch and tests that are slow, that > > should run on each merge. That will improve the feedback times. > > > > So let's apply that in the future. > For now the amount of merges done is enormous, and it will be impossible to > get things merged on a reasonable time. > Again, I'm not against testing, but it should be done the right way... > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: de...@ovirt.org, infra@ovirt.org > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > Hi! > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > propose creating a new gerrit flag (Tests) with the following > > > > specifics: > > > > > > > > > > > > +1 - Tests passed/overrided > > > > 0 - Tests pending > > > > -1 - Tests broken > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > > the process. > > > > > > > > That way all the tests will be blocked until someone (hopefully > > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > > value, she just has to set that flag herself. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -- > > > > David Caro > > > > > > > > Red Hat S.L. > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > Tel.: +420 532 294 605 > > > > Email: dc...@redhat.com > > > > Web: www.redhat.com > > > > RHT Global #: 82-62605 > > > > > > > > ___ > > > > Devel mailing list > > > > de...@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > -- > > David Caro > > > > Red Hat S.L. > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > Tel.: +420 532 294 605 > > Email: dc...@redhat.com > > Web: www.redhat.com > > RHT Global #: 82-62605 > > > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "David Caro" > To: "Oved Ourfali" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 12:12:19 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > On 12/09, Oved Ourfali wrote: > > What happens when rebasing? > > We can't afford waiting for tests to run on each rebase... as we might end > > up rebasing forever. > > For now we will have to, all the code that is going to be merged must > be tested as it is going to be merged, that means running the tests in > the last rebase too. > > In the future there are plans on using a gating system like zuul, so > zuul will be the one monitoring the tests and merging when passes, so > you will just add the flag, and that will trigger the gate, that runs > the tests and merged the patch. > > It's unlikely that you'll have to wait forever, but there's nothing > avoiding you doing that (right now even). > > I'd like to put emphasis again on differentiating between tests that > are fast, that should run on each patch and tests that are slow, that > should run on each merge. That will improve the feedback times. > So let's apply that in the future. For now the amount of merges done is enormous, and it will be impossible to get things merged on a reasonable time. Again, I'm not against testing, but it should be done the right way... > > > > - Original Message - > > > From: "David Caro" > > > To: de...@ovirt.org, infra@ovirt.org > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > Hi! > > > > > > e have been having an issue with gerrit patches being merged before > > > jenkins ran any tests on them, to avoid it from happening again I > > > propose creating a new gerrit flag (Tests) with the following > > > specifics: > > > > > > > > > +1 - Tests passed/overrided > > > 0 - Tests pending > > > -1 - Tests broken > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > passing the tests and -1 is set by jenkins in case it breaks any > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > the process. > > > > > > That way all the tests will be blocked until someone (hopefully > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > value, she just has to set that flag herself. > > > > > > > > > What do you think? > > > > > > > > > -- > > > David Caro > > > > > > Red Hat S.L. > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > Tel.: +420 532 294 605 > > > Email: dc...@redhat.com > > > Web: www.redhat.com > > > RHT Global #: 82-62605 > > > > > > ___ > > > Devel mailing list > > > de...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
- Original Message - > From: "Yaniv Dary" > To: "Oved Ourfali" > Cc: infra@ovirt.org, de...@ovirt.org > Sent: Tuesday, December 9, 2014 12:11:31 PM > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > - Original Message - > > From: "Yaniv Dary" > > To: "Oved Ourfali" > > Cc: de...@ovirt.org, infra@ovirt.org > > Sent: Tuesday, December 9, 2014 12:10:36 PM > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > > > - Original Message - > > > From: "Oved Ourfali" > > > To: "David Caro" > > > Cc: infra@ovirt.org, de...@ovirt.org > > > Sent: Tuesday, December 9, 2014 11:52:11 AM > > > Subject: Re: [ovirt-devel] Creating a new gerrit flag > > > > > > What happens when rebasing? > > > We can't afford waiting for tests to run on each rebase... as we might > > > end > > > up > > > rebasing forever. > > > > why can't you rerun tests after rebase to run tests if the patch is > > critical > > and pending? > > I meant manually. > You can run. The issue is that while running them, someone else can merge something, and then you'll need to rebase again... and again... and again... > > > > > > > > - Original Message - > > > > From: "David Caro" > > > > To: de...@ovirt.org, infra@ovirt.org > > > > Sent: Tuesday, December 9, 2014 11:43:04 AM > > > > Subject: [ovirt-devel] Creating a new gerrit flag > > > > > > > > Hi! > > > > > > > > e have been having an issue with gerrit patches being merged before > > > > jenkins ran any tests on them, to avoid it from happening again I > > > > propose creating a new gerrit flag (Tests) with the following > > > > specifics: > > > > > > > > > > > > +1 - Tests passed/overrided > > > > 0 - Tests pending > > > > -1 - Tests broken > > > > > > > > where +1 is required to submit, +1 is set by jenkins when > > > > passing the tests and -1 is set by jenkins in case it breaks any > > > > tests. The +1 flag can be set also by maintainers to allow overriding > > > > the process. > > > > > > > > That way all the tests will be blocked until someone (hopefully > > > > jenkins) adds the +1 flag, but if the maintainer wants to override the > > > > value, she just has to set that flag herself. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -- > > > > David Caro > > > > > > > > Red Hat S.L. > > > > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > > > > > > > Tel.: +420 532 294 605 > > > > Email: dc...@redhat.com > > > > Web: www.redhat.com > > > > RHT Global #: 82-62605 > > > > > > > > ___ > > > > Devel mailing list > > > > de...@ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > > > Devel mailing list > > > de...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] Creating a new gerrit flag
What happens when rebasing? We can't afford waiting for tests to run on each rebase... as we might end up rebasing forever. - Original Message - > From: "David Caro" > To: de...@ovirt.org, infra@ovirt.org > Sent: Tuesday, December 9, 2014 11:43:04 AM > Subject: [ovirt-devel] Creating a new gerrit flag > > Hi! > > e have been having an issue with gerrit patches being merged before > jenkins ran any tests on them, to avoid it from happening again I > propose creating a new gerrit flag (Tests) with the following > specifics: > > > +1 - Tests passed/overrided > 0 - Tests pending > -1 - Tests broken > > where +1 is required to submit, +1 is set by jenkins when > passing the tests and -1 is set by jenkins in case it breaks any > tests. The +1 flag can be set also by maintainers to allow overriding > the process. > > That way all the tests will be blocked until someone (hopefully > jenkins) adds the +1 flag, but if the maintainer wants to override the > value, she just has to set that flag herself. > > > What do you think? > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ovirt-devel] [URGENT][ACTION REQUIRED] oVirt engine on branch 3.5 doesn't build anymore
>From my small experience with Zanata, I don't think that manual changes are >the right way to go.. However, it also wouldn't do much harm as the fix limited to one entry, so due to the urgency I believe it would be best to merge it (assuming it indeed fixes the issue), and straighten things up later. Oved - Original Message - > From: "Tomas Jelinek" > To: "Sandro Bonazzola" > Cc: "infra" , de...@ovirt.org > Sent: Thursday, September 11, 2014 9:52:34 AM > Subject: Re: [ovirt-devel] [URGENT][ACTION REQUIRED] oVirt engine on branch > 3.5 doesn't build anymore > > so this [1] is the fix I was talking about, going to try to build it locally > with language permutations enabled. > > Might take a while... Let you know how did it end. > > [1]: http://gerrit.ovirt.org/#/c/32802/1 > > - Original Message - > > From: "Sandro Bonazzola" > > To: de...@ovirt.org, "infra" > > Sent: Thursday, September 11, 2014 8:14:02 AM > > Subject: [ovirt-devel] [URGENT][ACTION REQUIRED] oVirt engine on branch 3.5 > > doesn't build anymore > > > > Hi, > > we should release oVirt 3.5.0 RC2 today but looks like it doesn't build > > anymore. > > Can you please fix it as soon as possible? > > > > See: http://jenkins.ovirt.org/job/ovirt-engine_3.5_create-rpms_merged/221/ > > Thanks, > > > > -- > > Sandro Bonazzola > > Better technology. Faster innovation. Powered by community collaboration. > > See how it works at redhat.com > > ___ > > Devel mailing list > > de...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > Devel mailing list > de...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
