[JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-416?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-416:
-------------------------------------------------
[~sbonazolla(a)redhat.com] [~mperina] do you know if today check-merged.sh in ovirt-engine is building the same RPMs as build-artifacts?
Potentially they can be different since its a different bash script, but if they are the same we can save a lot of time running duplicate rpm builds...
Now that we enabled GWT compilation per patch, maybe we can drop the rpm build on check-merged.sh and just do it in build-artifacts?
we'll find an error in either jobs anyway.. what do you think?
> [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any
> -------------------------------------------------------------------------------------
>
> Key: OVIRT-416
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-416
> Project: oVirt - virtualization made easy
> Issue Type: Improvement
> Reporter: David Caro Estevez
> Assignee: infra
>
> Right now most projects just rebuild twice the artifacts, what for some means a big waste of resources, if we could just reuse what was built previously there would be no rebuilding.
> Something to take into account is that the distributions that check-merged and build-artifacts run for might not match, so you can be running check-merged only on fc23 but building artifacts for fc23, fc22 an el7 (as an example), maybe we should not allow different distros on each stage?|
--
This message was sent by Atlassian JIRA
(v1000.184.1#100008)
8 years, 3 months
bad image on ovirt-image-repository "Fedora 24 Cloud Base Image v20160712"
by Yedidyah Bar David
Hi all,
When trying importing this image in the web admin, it fails.
engine.log might indicate a problem on the glace server:
2016-07-28 09:44:14,860 ERROR
[org.ovirt.engine.core.bll.storage.repoimage.ImportRepoImageCommand]
(default task-7) [47a28910] Error during ValidateFailure.:
com.woorea.openstack.base.client.OpenStackResponseException: Internal
Server Error
Please handle. Thanks.
Also, it's a bit unclear what are
"Fedora 24 Cloud Base Image v20160712 for x86_64 (4490284)" and
"Fedora 24 Cloud Base Image v1.2 for x86_64 (2faafb6)". If they
have different purposes, please clarify in their names. If one
is simply older, it might be better to remove it. Thanks.
Best,
--
Didi
8 years, 3 months
[JIRA] (OVIRT-633) Re: [ovirt-devel] [ACTION REQUIRED] broken dependency with vdsm git6e84643
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-633?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-633:
--------------------------------------------
Resolution: Fixed
Status: Done (was: Blocked)
> Re: [ovirt-devel] [ACTION REQUIRED] broken dependency with vdsm git6e84643
> --------------------------------------------------------------------------
>
> Key: OVIRT-633
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-633
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: sbonazzo
> Assignee: infra
>
> On Wed, Jul 13, 2016 at 10:14 AM, Michal Skrivanek <
> michal.skrivanek(a)redhat.com> wrote:
> >
> > > On 13 Jul 2016, at 09:42, Nir Soffer <nsoffer(a)redhat.com> wrote:
> > >
> > > On Wed, Jul 13, 2016 at 10:04 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
> > wrote:
> > >> DEBUG util.py:417: Error: Package:
> > >> vdsm-4.18.999-232.git6e84643.el7.centos.x86_64 (ovirt-master-snapshot)
> > >> DEBUG util.py:417: Requires: safelease >= 1.0-7
> > >> DEBUG util.py:417: Available: safelease-1.0-5.el7.x86_64
> > >> (centos-epel)
> > >> DEBUG util.py:417: safelease = 1.0-5.el7
> > >
> > > Yaniv, 1.0-7 not available on centos?
> >
> >
> > https://dl.fedoraproject.org/pub/epel/7/x86_64/s/safelease-1.0-7.el7.x86_...
> > Sandro, wrong repos set up?
> >
> >
> Maybe mirror not aligned or proxy issue. Adding infra.
> > >
> > >>
> > >>
> > >> --
> > >> Sandro Bonazzola
> > >> Better technology. Faster innovation. Powered by community
> > collaboration.
> > >> See how it works at redhat.com
> > >>
> > >> _______________________________________________
> > >> Devel mailing list
> > >> Devel(a)ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/devel
> > > _______________________________________________
> > > Devel mailing list
> > > Devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > >
> > >
> >
> >
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
--
This message was sent by Atlassian JIRA
(v1000.184.1#100008)
8 years, 3 months
[JIRA] (OVIRT-612) Support to FTP files for Kimchi Project
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-612?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-612:
-------------------------------------------------
Hey,
Did you got a chance to read on the standard CI ? do you need help in adding the 1st job?
> Support to FTP files for Kimchi Project
> ---------------------------------------
>
> Key: OVIRT-612
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-612
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Paulo Ricardo Paz Vital
> Assignee: infra
>
> Hello,
> Kimchi is a sub-project of oVirt and we are planning to make available to users
> simple qcow2 image files of Fedora 23, OpenSUSE 42.1 and Ubuntu 16.04 with
> Kimchi installed in there.
> We need support to store the files and make them available to download, in a
> service like FTP. Since Kimchi mailing lists already use oVirt infrastructure,
> I'd like to know if it's possible to be supported by oVirt and how to do that.
> Thanks and best regards, Paulo.
> --
> Paulo Ricardo Paz Vital
> Linux Technology Center, IBM Systems
> http://www.ibm.com/linux/ltc/
--
This message was sent by Atlassian JIRA
(v1000.184.1#100008)
8 years, 3 months
[JIRA] (OVIRT-612) Support to FTP files for Kimchi Project
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-612?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-612:
--------------------------------------------
Blocked By: waiting for customer
Status: Blocked (was: To Do)
> Support to FTP files for Kimchi Project
> ---------------------------------------
>
> Key: OVIRT-612
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-612
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Paulo Ricardo Paz Vital
> Assignee: infra
>
> Hello,
> Kimchi is a sub-project of oVirt and we are planning to make available to users
> simple qcow2 image files of Fedora 23, OpenSUSE 42.1 and Ubuntu 16.04 with
> Kimchi installed in there.
> We need support to store the files and make them available to download, in a
> service like FTP. Since Kimchi mailing lists already use oVirt infrastructure,
> I'd like to know if it's possible to be supported by oVirt and how to do that.
> Thanks and best regards, Paulo.
> --
> Paulo Ricardo Paz Vital
> Linux Technology Center, IBM Systems
> http://www.ibm.com/linux/ltc/
--
This message was sent by Atlassian JIRA
(v1000.184.1#100008)
8 years, 3 months
[JIRA] (OVIRT-662) fix race between jobs on CI check patch jobs
by eyal edri [Administrator] (oVirt JIRA)
eyal edri [Administrator] created OVIRT-662:
-----------------------------------------------
Summary: fix race between jobs on CI check patch jobs
Key: OVIRT-662
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-662
Project: oVirt - virtualization made easy
Issue Type: Bug
Reporter: eyal edri [Administrator]
Assignee: infra
Today we have some projects with an additional job that runs other than check-patch.sh, which causes a race that can result in -1 being overridden if the output from another successful job is returned after the -1.
--
This message was sent by Atlassian JIRA
(v1000.184.1#100008)
8 years, 3 months
[JIRA] (OVIRT-634) sending POST/PUT to gerrit to ... set a topic for example.
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-634?page=com.atlassian.jira... ]
eyal edri [Administrator] reassigned OVIRT-634:
-----------------------------------------------
Assignee: Shlomo Ben David (was: infra)
> sending POST/PUT to gerrit to ... set a topic for example.
> ----------------------------------------------------------
>
> Key: OVIRT-634
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-634
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Martin Mucha
> Assignee: Shlomo Ben David
>
> Hi,
> I'd like to ask, whether:
> a) is even possible to pass requests to do some modifications on gerrit
> b) if it is, then when I'd be glad if you can inform me, what I'm doing wrong in following command [1]
> c) if it's not currently possible to pass such requests, I'd like to ask if they can be allowed.
> Motivation: I have quite often longer topics, like 10 patches. Due to our work style they need to be rebased often and reverified. Or I need to specify same reviewers to all of them. etc. etc. This means I have to open *all* of them (takes ages to load) and do same actions over and over, which is time waste. Also, gerrit is (apparently) not designed to work under 'heavy' load, which means, that quite often page isn't loaded successfully. For example change is loaded, but allegedly I'm not logged in (which is not true), and because of that I have to hit refresh. This means, that I'm generating a lot of unnecessary load for gerrit server, while what I'd actually like to do is for example set topic to 10 patches, for which I do not need whole detail with all revisions to be loaded.
> [1]
> curl --digest -v -H Content-Type:application/json -u "mmucha:pass" -X PUT https://gerrit.ovirt.org/changes/58620/topic -d '{"topic":"test"}'
> this return 403, and I'd like to know, if this is because of error in this command, or because this type of operations are generally not allowed.
> Thanks,
> M.
--
This message was sent by Atlassian JIRA
(v1000.184.1#100008)
8 years, 3 months