Maintainership request
Hi We need to add the following users as maintainers of ovirt-imageio please: - derez - laravot Thanks, Amit ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Find bugs can't handle UIConstants
Hi, CI failing my patches due to the following message: http://jenkins.ovirt.org/job/ovirt-engine_4.0_find-bugs_created/361/findbugsResult/new/ Thanks ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: vdsm_master_check-patch-el7 job is failing
Thanks, will rebase
On Tue, May 24, 2016 at 1:55 PM, Dan Kenigsberg wrote:
> On Tue, May 24, 2016 at 10:22:16AM +0200, David Caro wrote:
> > On 05/24 11:07, Amit Aviram wrote:
> > > Hi.
> > > For the last day I am getting this error over and over again from
> jenkins:
> > >
> > > Start: yum install*07:23:55* ERROR: Command failed. See logs for
> > > output.*07:23:55* # /usr/bin/yum-deprecated --installroot
> > >
> /var/lib/mock/epel-7-x86_64-cc6e9a99555654260f7f229c124a6940-31053/root/
> > > --releasever 7 install @buildsys-build
> > > --setopt=tsflags=nocontexts*07:23:55* WARNING: unable to delete
> > > selinux filesystems (/tmp/mock-selinux-plugin.3tk4zgr4): [Errno 1]
> > > Operation not permitted: '/tmp/mock-selinux-plugin.3tk4zgr4'*07:23:55*
> > > Init took 3 seconds
> > >
> > >
> > > (see
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/2026/)
> > >
> > >
> > > This fails the job, so I get -1 from Jenkins CI for my patch.
> >
> >
> > That's not what's failing the job, is just a warning, the failure is
> happening
> > before that, when installing the chroot:
> >
> > 07:23:53 Start: yum install
> > 07:23:55 ERROR: Command failed. See logs for output.
> > 07:23:55 # /usr/bin/yum-deprecated --installroot
> /var/lib/mock/epel-7-x86_64-cc6e9a99555654260f7f229c124a6940-31053/root/
> --releasever 7 install @buildsys-build --setopt=tsflags=nocontexts
> >
> > Checking the logs (logs.tgz file, archived on the job, under
> > vdsm/logs/mocker-epel-7-x86_64.el7.init/root.log):
> >
> >
> > DEBUG util.py:417:
> https://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/repodata/repomd.xml:
> [Errno 14] HTTPS Error 404 - Not Found
> > DEBUG util.py:417: Trying other mirror.
> > DEBUG util.py:417: One of the configured repositories failed ("Custom
> openstack-kilo"),
> > DEBUG util.py:417: and yum doesn't have enough cached data to
> continue. At this point the only
> > DEBUG util.py:417: safe thing yum can do is fail. There are a few ways
> to work "fix" this:
> > DEBUG util.py:417: 1. Contact the upstream for the repository and
> get them to fix the problem.
> > DEBUG util.py:417: 2. Reconfigure the baseurl/etc. for the
> repository, to point to a working
> > DEBUG util.py:417: upstream. This is most often useful if you
> are using a newer
> > DEBUG util.py:417: distribution release than is supported by
> the repository (and the
> > DEBUG util.py:417: packages for the previous distribution
> release still work).
> > DEBUG util.py:417: 3. Disable the repository, so yum won't use it
> by default. Yum will then
> > DEBUG util.py:417: just ignore the repository until you
> permanently enable it again or use
> > DEBUG util.py:417: --enablerepo for temporary usage:
> > DEBUG util.py:417: yum-config-manager --disable
> openstack-kilo
> > DEBUG util.py:417: 4. Configure the failing repository to be
> skipped, if it is unavailable.
> > DEBUG util.py:417: Note that yum will try to contact the repo.
> when it runs most commands,
> > DEBUG util.py:417: so will have to try and fail each time (and
> thus. yum will be be much
> > DEBUG util.py:417: slower). If it is a very temporary problem
> though, this is often a nice
> > DEBUG util.py:417: compromise:
> > DEBUG util.py:417: yum-config-manager --save
> --setopt=openstack-kilo.skip_if_unavailable=true
> > DEBUG util.py:417: failure: repodata/repomd.xml from openstack-kilo:
> [Errno 256] No more mirrors to try.
> >
> >
> > So it seems that the repo does not exist anymore, there's a README.txt
> file
> > though that says:
> >
> > RDO Kilo is hosted in CentOS Cloud SIG repository
> > http://mirror.centos.org/centos/7/cloud/x86_64/openstack-kilo/
> >
> > And that new link seems to work ok, so probably you just need to change
> the
> > automation/*.repos files on vdsm git repo to point to the new openstack
> repos
> > url instead of the old one and everything should work ok.
> >
> >
> >
> > >
> > > I am pretty sure it is not related to the patch. also fc23 job passes.
> > >
> > >
> > > Any idea what's the problem?
>
> Yep, I believe that https://gerrit.ovirt.org/57870 has solved that.
> Please rebase on top of current ovirt-3.6 branch.
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
vdsm_master_check-patch-el7 job is failing
Hi. For the last day I am getting this error over and over again from jenkins: Start: yum install*07:23:55* ERROR: Command failed. See logs for output.*07:23:55* # /usr/bin/yum-deprecated --installroot /var/lib/mock/epel-7-x86_64-cc6e9a99555654260f7f229c124a6940-31053/root/ --releasever 7 install @buildsys-build --setopt=tsflags=nocontexts*07:23:55* WARNING: unable to delete selinux filesystems (/tmp/mock-selinux-plugin.3tk4zgr4): [Errno 1] Operation not permitted: '/tmp/mock-selinux-plugin.3tk4zgr4'*07:23:55* Init took 3 seconds (see http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/2026/) This fails the job, so I get -1 from Jenkins CI for my patch. I am pretty sure it is not related to the patch. also fc23 job passes. Any idea what's the problem? Thanks ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Packaging a new project
Hi infra. For 4.0, the new image upload feature is going to be added, and as some of you already know we've created a new project ( https://gerrit.ovirt.org/#/admin/projects/ovirt-imageio) containing 2 small applications and a common library. A reminder- - one of the applications (called "ovirt-imageio-daemon") is supposed to run in a VDSM host. - Other application (called "ovirt-imageio-proxy") is supposed to run as a proxy, could be on a standalone host or in the engine's host. My question for you is, what else do we need except for a Makefile that builds rpms, for the project to be ready to be released to public repos? Thanks, Amit. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[JIRA] (OVIRT-506) please put my Jenkins aaviram, in dev role group
Amit Aviram created OVIRT-506: - Summary: please put my Jenkins aaviram, in dev role group Key: OVIRT-506 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-506 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Amit Aviram Assignee: infra -- This message was sent by Atlassian JIRA (v7.2.0-OD-05-030#72002) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
[JIRA] (OVIRT-440) Gerrit's project name change request
Amit Aviram created OVIRT-440: - Summary: Gerrit's project name change request Key: OVIRT-440 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-440 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Amit Aviram Assignee: infra Hello. We've initiated the "vdsm-imaged" project, and need to change its name to "ovirt-imageio". what should we do? -- This message was sent by Atlassian JIRA (v7.2.0-OD-03-014#72000) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Gerrit's project name change request
Hello. We've initiated the "vdsm-imaged" project, and need to change its name to "ovirt-imageio". what should we do? ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Actively triggering of CI jobs
On Wed, Dec 9, 2015 at 12:15 PM, David Caro wrote:
> On 12/09 12:00, Amit Aviram wrote:
> > On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren
> wrote:
> >
> > > >>> > [1]: http://www.ovirt.org/CI/Build_and_test_standards
> > > >>> >
> > > >
> > > > That's nice, but most of us are not aware of all that..
> > > >
> > >
> > > Well, we can do a better job advocating that, I try to mention this
> > > almost in any infra/devel thread where 'CI' is mentioned.
> > > I'm open to suggestions about how to make developers more aware of the
> > > fact that the ultimate power to determine what happens in CI had
> > > mostly been placed in their hands...
> >
> >
> > What I'm offering is not letting us a choice, exactly because what you
> are
> > saying regarding the fact that most of the influence of what happens in
> CI
> > is in our hands. otherwise what happens is the current situation where
> > some/most of the developers are not aware of their options, or misses the
> > mails or whatever..
> >
> >
> > > >
> > > > From what I'm seeing, most of the developers here don't make their
> > > patches
> > > > drafts.. moreover,
> > > > - personally I didn't even know that it will not trigger jobs if it
> is a
> > > > draft. (and I'm not the only one)
> > >
> > > Well, now you know... Adding 'devel' with hope more devs will read
> this.
> > >
> > > > - sometimes I need to label my patches, therefor can't make it a
> draft
> > > >
> > > By 'label' you mean set topic?
> > > Not sure those are mutually exclusive, 'git review' options seem to
> > > indicate they are not. I will look deeper into that.
> > >
> > > > nowadays we are waiting for the jobs too much to finish. and the
> reality
> > > is
> > > > that too much jobs shouldn't run at all- despite all of the nice
> things
> > > you
> > > > guys show here..
> > >
> > > I which cases besides the patch not being "ready" (=draft...) should
> > > jobs not run?
> > >
> >
> > Most of the review process doesn't need the jobs to run. a patch has
> 5-10,
> > and sometimes much more sets until it is being merged- you don't need to
> > run the jobs every single time you are updating your patch..
> >
> >
> > >
> > > >
> > > > I still think that it will be a better solution to force the
> developer to
> > > > activate the tests manually (by adding a flag when pushing or even
> doing
> > > it
> > > > with the jenkins client..)
> > > >
> > > We tried to add the 'workflow' flag for that at some point (It is used
> > > by most infra projects), but it was not accepted with any enthusiasm
> > > by the devs, you can search back the discussion on 'devel'.
> >
> >
> > The workflow makes job DISABLING optional.
> > I'm suggesting making job ENABLING optional, with some other flag..
> > As we must run it to merge- it won't be missed, and will be triggered
> only
> > when needed.
>
> That's not true, the workflow make job enabling optional, if you don't set
> it,
> it will not run
>
So I think we should use it :)
Why was it rejected?
> >
> >
> >
> > >
> > > --
> > > Barak Korren
> > > bkor...@redhat.com
> > > RHEV-CI Team
> > >
>
> > ___
> > 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
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
Re: Actively triggering of CI jobs
On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren wrote: > >>> > [1]: http://www.ovirt.org/CI/Build_and_test_standards > >>> > > > > > That's nice, but most of us are not aware of all that.. > > > > Well, we can do a better job advocating that, I try to mention this > almost in any infra/devel thread where 'CI' is mentioned. > I'm open to suggestions about how to make developers more aware of the > fact that the ultimate power to determine what happens in CI had > mostly been placed in their hands... What I'm offering is not letting us a choice, exactly because what you are saying regarding the fact that most of the influence of what happens in CI is in our hands. otherwise what happens is the current situation where some/most of the developers are not aware of their options, or misses the mails or whatever.. > > > > From what I'm seeing, most of the developers here don't make their > patches > > drafts.. moreover, > > - personally I didn't even know that it will not trigger jobs if it is a > > draft. (and I'm not the only one) > > Well, now you know... Adding 'devel' with hope more devs will read this. > > > - sometimes I need to label my patches, therefor can't make it a draft > > > By 'label' you mean set topic? > Not sure those are mutually exclusive, 'git review' options seem to > indicate they are not. I will look deeper into that. > > > nowadays we are waiting for the jobs too much to finish. and the reality > is > > that too much jobs shouldn't run at all- despite all of the nice things > you > > guys show here.. > > I which cases besides the patch not being "ready" (=draft...) should > jobs not run? > Most of the review process doesn't need the jobs to run. a patch has 5-10, and sometimes much more sets until it is being merged- you don't need to run the jobs every single time you are updating your patch.. > > > > > I still think that it will be a better solution to force the developer to > > activate the tests manually (by adding a flag when pushing or even doing > it > > with the jenkins client..) > > > We tried to add the 'workflow' flag for that at some point (It is used > by most infra projects), but it was not accepted with any enthusiasm > by the devs, you can search back the discussion on 'devel'. The workflow makes job DISABLING optional. I'm suggesting making job ENABLING optional, with some other flag.. As we must run it to merge- it won't be missed, and will be triggered only when needed. > > -- > Barak Korren > bkor...@redhat.com > RHEV-CI Team > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Actively triggering of CI jobs
On Wed, Dec 9, 2015 at 10:05 AM, Eyal Edri wrote: > +1, > this will be the best suggestion. > we can try adding a manual trigger for drafts if needed, still need to > check if possible. > > e. > > On Wed, Dec 9, 2015 at 9:38 AM, Eli Mesika wrote: > >> >> >> - Original Message ----- >> > From: "Barak Korren" >> > To: "Amit Aviram" >> > Cc: "infra" >> > Sent: Tuesday, December 8, 2015 5:16:30 PM >> > Subject: Re: Actively triggering of CI jobs >> > >> > > I was thinking, maybe it would be better if we will explicitly >> require to >> > > run the CI jobs when we push patches.. then only when the developer >> will >> > > need the job's feedback it will be activated. no redundant jobs will >> run, >> > > and we will wait much less for the jobs to finish when we will >> actually >> > > need >> > > them. >> >> Why not simply submit your patches as a Draft until the point you want CI >> to run on them, then you can simply publish them ... >> This is the way I am using and it's simple ... >> >> > > >> > It seems to me that it will me too easy to forget to run the CI this >> way. >> > We barely merge patches that did not pass the CI tests.. only if it fails on general errors that doesn't belong the patch's context. but it is part of the developing process, we can't just forget to using it. that means that it is mandatory to run it at some point if a developer wants his patches to be merged. which means the developer runs it *only* when it is ready to be merged. (much much less triggered jobs!) > > >> > There is another way though - To make the jobs do a lot less work. >> > Most anything has to do what what actually happens in CI resides in >> > the project`s automation directory now days (see [1]). If you want to >> > make CI smarter so it will not do things it shouldn't be doing, all >> > you need to do is customize the automation scripts to be smarter and >> > run only the needed tests for the files that were changed by the >> > patch. >> > >> > [1]: http://www.ovirt.org/CI/Build_and_test_standards >> > >> > That's nice, but most of us are not aware of all that.. > > -- >> > Barak Korren >> > bkor...@redhat.com >> > RHEV-CI Team >> > ___ >> > 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 >> >> >> > > > -- > Eyal Edri > Supervisor, RHEV CI > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) > >From what I'm seeing, most of the developers here don't make their patches drafts.. moreover, - personally I didn't even know that it will not trigger jobs if it is a draft. (and I'm not the only one) - sometimes I need to label my patches, therefor can't make it a draft nowadays we are waiting for the jobs too much to finish. and the reality is that too much jobs shouldn't run at all- despite all of the nice things you guys show here.. I still think that it will be a better solution to force the developer to activate the tests manually (by adding a flag when pushing or even doing it with the jenkins client..) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Actively triggering of CI jobs
Hi all. I wanted to bring up something that might make our work with CI a bit more efficient. As developers, we obviously use Jenkins in every step we are taking in the developing process. Each patch that is pushed- or at least a big amount of our patches- triggers Jenkins jobs automatically. I can say that for myself, most of my push actions do not require any CI jobs to run. Thus reviewing and updating patches include work that triggers tons of redundant jobs that make the system slow for the jobs that are actually needed.. I was thinking, maybe it would be better if we will explicitly require to run the CI jobs when we push patches.. then only when the developer will need the job's feedback it will be activated. no redundant jobs will run, and we will wait much less for the jobs to finish when we will actually need them. Is that possible for implementation? Thanks, Amit. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Findbugs failure
Hi, it seems there is some problem to run dao tests: http://jenkins.ovirt.org/job/ovirt-engine_3.6_dao-unit-tests_created/8/ This is failing our patches, can you please have a look? Thanks. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
New open-ID account
Hi, my new account-ID is 1000827. my previous account email was amitavi...@gmail.com. Thanks, Amit. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
gerrit user
Hello. I've used google-id until now, and I'm switching my gerrit user to aavi...@redhat.com. is this enough or am I need to actually use another oped-id client? If it is enough- I'll appreciate if this user could get the needed permissions to work in gerrit on the ovirt&VDSM projects. Thanks in advance, and regards- Amit. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
User can't be added as a reviewer in gerrit
Hello, my user can't be added as a reviewer. what can I do to fix this? (I have 2 registered: aavi...@redhat.com, amitavi...@gmail.com- would like to keep the gmail one since all my patches and work was uploaded through it) ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Gerrit problem
Hi. I'm having a problem with Gerrit. When people try adding me as a reviewer, they see my name twice (aavi...@redhat.com) and when they try to add me as a reviewer they get the following message: "Amit Aviram does not identify a registered user or group" My account number is 1000627. Hope you can help :) Thanks a lot, Amit. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
"No JDK named ?(Default)? found" when running a test with jenkins
Hello, I've uploaded a patch with gerrit and jenkins returned the following error to me: Triggered by Gerrit: http://gerrit.ovirt.org/34555 No JDK named ?(Default)? found Building remotely on os1-rhel6-vm02 (el6 centos6 os1) in workspace /home/jenkins/workspace/ovirt-engine_master_unit-tests_gerrit Deleting project workspace... FATAL: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown: java.util.concurrent.TimeoutException: Ping started on 1414929198741 hasn't completed at 1414929438742 hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown: java.util.concurrent.TimeoutException: Ping started on 1414929198741 hasn't completed at 1414929438742 at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:739) at hudson.FilePath.act(FilePath.java:911) at hudson.FilePath.act(FilePath.java:895) at hudson.FilePath.exists(FilePath.java:1343) at hudson.plugins.ws_cleanup.PreBuildCleanup.preCheckout(PreBuildCleanup.java:89) at jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:76) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown: java.util.concurrent.TimeoutException: Ping started on 1414929198741 hasn't completed at 1414929438742 at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:802) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:951) at hudson.remoting.Channel$2.handle(Channel.java:475) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: hudson.remoting.Channel$OrderlyShutdown: java.util.concurrent.TimeoutException: Ping started on 1414929198741 hasn't completed at 1414929438742 ... 3 more Caused by: Command close created at at hudson.remoting.Command.(Command.java:56) at hudson.remoting.Channel$CloseCommand.(Channel.java:945) at hudson.remoting.Channel$CloseCommand.(Channel.java:943) at hudson.remoting.Channel.close(Channel.java:1026) at hudson.slaves.ChannelPinger$1.onDead(ChannelPinger.java:110) at hudson.remoting.PingThread.ping(PingThread.java:120) at hudson.remoting.PingThread.run(PingThread.java:81) Caused by: java.util.concurrent.TimeoutException: Ping started on 1414929198741 hasn't completed at 1414929438742 ... 2 more I believe this is because one of the VMs does not have a JDK installed? thank you, Amit. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
