False CI-1 due to unreachable copr-be.cloud.fedoraproject.org

Description

Many patches on
https://gerrit.ovirt.org/#/q/topic:passthroughMigration fail CI due to

failure: repodata/repomd.xml from patternfly: [Errno 256] No more
mirrors to try.
http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-7-x86_64/repodata/repomd.xml:
[Errno 14] curl#7 - "Failed connect to
copr-be.cloud.fedoraproject.org:80; No route to host"
http://copr-be.cloud.fedoraproject.org/results/patternfly/patternfly1/epel-7-x86_64

Activity

Show:

Greg Sheremeta January 25, 2017 at 3:12 PM

lol

yeah, it's working using Standard CI now. https://gerrit.ovirt.org/#/c/71135/ Hopefully I can get it merged soon. had one comment on the patch so far, about the version/release getting bumped on every build for repo purposes. No other comments yet.

Barak Korren January 25, 2017 at 10:10 AM

I think you need to be the one answering this question, not asking it...

Eyal Edri January 25, 2017 at 10:01 AM

once your new patches are merged, will we get patternfly from oVirt repos instead of copr?

Eyal Edri December 14, 2016 at 3:40 PM

NP, I'm just concerned if CI will keep failing because the copr repo isn't reliable.
If thats not an issue then we can wait for 4.2.

Also, if you are building it, we can add it to standard CI, and built it automatically.

Greg Sheremeta December 14, 2016 at 3:11 PM

We can move it.

How about we move it to ovirt's infra when we upgrade to patternfly3, which will happen for oVirt 4.2? I can name the rpm "ovirt-patternfly3". I'll need some help figuring out how to put it in the ovirt static repo.

Eyal Edri December 14, 2016 at 3:04 PM

What was the decision?
Can you move the patternfly to ovirt static repo?

Greg Sheremeta December 8, 2016 at 2:28 PM

> are you doing that manually

Yes, completely manual

> I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project.

True. However, we've talked about renaming the rpm to 'ovirt-patternflyX' to reflect the fact that it's only used by us. In that case, it might make sense to move it to our infra.

Barak Korren December 8, 2016 at 8:05 AM
Edited

are you doing that manually, or do you have some automation built around it?

I'm not sure oVirt's own infra would be the best place, because Patternfly is not strictly an oVirt project.
Perhaps make travis run the build in Copr, and then take the result and push it to GitHub's artifact storage?
Another possibility is to use BinTray

We might eventually mirror this in oVirt infra to make CI resilient to changes there (see )

Greg Sheremeta December 6, 2016 at 1:37 PM

I maintain patternfly on copr. No one else uses it, so we can move it anywhere that makes sense.

Eyal Edri December 6, 2016 at 12:54 PM

is it possible to get pattenfly from other place than Copr?
We're seeing more and more failures on repos hosted by copr, we might want to find a more stable repo on other services.
Who is building/maintaining those builds?

Barak Korren December 6, 2016 at 12:44 PM

Which projects are coming from Copr? Maybe they would like us to host their artifacts on resources.ovirt.org (And would happily make their CI systems update it with new builds)? Or perhaps they would push into Fedora? or EPEL? or CentOS? Or even just GitHub?

I guess if we setup out own mirrors for stuff it will solve our problems, but a project that only releases on copr has a problem IMO....

Done

Details

Assignee

Reporter

Blocked By

Priority

Created December 5, 2016 at 10:58 AM
Updated January 30, 2017 at 9:25 AM
Resolved January 29, 2017 at 10:24 AM