[JIRA] (OVIRT-2944) RE: [ftpcom] oVirt mirror out of sync
by Shlomi Zidmi (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2944?page=com.atlassian.jir... ]
Shlomi Zidmi reassigned OVIRT-2944:
-----------------------------------
Assignee: Shlomi Zidmi (was: infra)
> RE: [ftpcom] oVirt mirror out of sync
> -------------------------------------
>
> Key: OVIRT-2944
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2944
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Erwin Bronkhorst - Studenten Net Twente
> Assignee: Shlomi Zidmi
>
> Hello Shlomi, hello infrastructure support team,
> > We have recently noticed you are quite out of sync with mirroring oVirt content (last synced more than a year ago).
> Thank you for bringing this issue to our attention. A while ago, we migrated to a new server and a new maintainer for the oVirt mirror, and something went definitely wrong in these processes. Sorry for the inconvenience.
> I think the major issue is that the public key that you have added is not in use anymore by us.
> Could you please replace the old key (for the mirror at ftp://ftp.snt.utwente.nl (Studenten Net Twente)) with this one?
> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDcEujUQ3DLIGiuOCg0ZlLqZhQY/uHFw2O9cMY6SrlG11tZ0oiwk6+x8dZsBN0kAN7zd1IIOo4+E0cMYUrkiwj6dzVc/oKY9RtTCOKhmqq1tnPxKSpOXY+CZxm7e63uVx8CpVjhj/lOMnfL3jzyBbNfURsSgY+6edSkDGzy3ptaXBDlrVI4F5+2rjKI3VgflshjUUZo1Di22snnZ5zoB8tT/Q8MBMjnMtQcPqjPL/VgfbgKwFfgLOnZtXzTnAjMK14IA5XLN9PCrPtEajRM8mtesqkYSMoZ1KqKPGwZspIijKrnoYNeKjkZxZAq9xijboj4GboHxsKRxckaw686qrfpPdPHNrgtKZZNxO5RB+/tgNLBM1l0g/9rEAN2Pvytg2Ifahk20oEodCzW1qsCBWl6+4NwV8iW87rgN+AgibNg/QmEd2SKNHAhOldEPFpHQqDRHo6ZJY5XbOEepK/ti3UOzV/mQ4u1PnKpZBoqWmM9MWBOEMZP7Ems4DHR5vdAvYs8TrzgTasoOe/MkFZ9FZ31XRL4loyPU9gid06ENA+Yc9xyRssUtjNsQfCNV+enSzbMBr4FvWmSoJNoVbQyi3tj13emflBqP+rROpeG7mgol+aP49z3RW56wOS0dhFqg8AXRyp1QLld/rJXzb3UH5l7WTXhX7DCuySezxhEyi1lGw== ftpcom(a)ftp.snt.utwente.nl
> Then I will try to set-up our scripting in order to get the mirror in sync as soon as possible.
> Kind regards,
> Erwin Bronkhorst
> FTPCom Studenten Net Twente
> Van: Shlomi Zidmi <szidmi(a)redhat.com>
> Verzonden: dinsdag 19 mei 2020 19:01
> Aan: ftpcom(a)snt.utwente.nl
> Onderwerp: [ftpcom] oVirt mirror out of sync
> Hello from the oVirt infrastructure team,
> We have recently noticed you are quite out of sync with mirroring oVirt content (last synced more than a year ago).
> If you are still interested in mirroring oVirt, please keep your mirror up to date with our public content.
> Otherwise, please let us know and you will be removed from our mirror list:
> https://www.ovirt.org/community/get-involved/repository-mirrors.html
> Thanks,
> Shlomi
> ------------
> oVirt community
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100127)
4 years, 6 months
[JIRA] (OVIRT-2944) RE: [ftpcom] oVirt mirror out of sync
by Erwin Bronkhorst - Studenten Net Twente (oVirt JIRA)
Erwin Bronkhorst - Studenten Net Twente created OVIRT-2944:
--------------------------------------------------------------
Summary: RE: [ftpcom] oVirt mirror out of sync
Key: OVIRT-2944
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2944
Project: oVirt - virtualization made easy
Issue Type: By-EMAIL
Reporter: Erwin Bronkhorst - Studenten Net Twente
Assignee: infra
Hello Shlomi, hello infrastructure support team,
> We have recently noticed you are quite out of sync with mirroring oVirt content (last synced more than a year ago).
Thank you for bringing this issue to our attention. A while ago, we migrated to a new server and a new maintainer for the oVirt mirror, and something went definitely wrong in these processes. Sorry for the inconvenience.
I think the major issue is that the public key that you have added is not in use anymore by us.
Could you please replace the old key (for the mirror at ftp://ftp.snt.utwente.nl (Studenten Net Twente)) with this one?
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDcEujUQ3DLIGiuOCg0ZlLqZhQY/uHFw2O9cMY6SrlG11tZ0oiwk6+x8dZsBN0kAN7zd1IIOo4+E0cMYUrkiwj6dzVc/oKY9RtTCOKhmqq1tnPxKSpOXY+CZxm7e63uVx8CpVjhj/lOMnfL3jzyBbNfURsSgY+6edSkDGzy3ptaXBDlrVI4F5+2rjKI3VgflshjUUZo1Di22snnZ5zoB8tT/Q8MBMjnMtQcPqjPL/VgfbgKwFfgLOnZtXzTnAjMK14IA5XLN9PCrPtEajRM8mtesqkYSMoZ1KqKPGwZspIijKrnoYNeKjkZxZAq9xijboj4GboHxsKRxckaw686qrfpPdPHNrgtKZZNxO5RB+/tgNLBM1l0g/9rEAN2Pvytg2Ifahk20oEodCzW1qsCBWl6+4NwV8iW87rgN+AgibNg/QmEd2SKNHAhOldEPFpHQqDRHo6ZJY5XbOEepK/ti3UOzV/mQ4u1PnKpZBoqWmM9MWBOEMZP7Ems4DHR5vdAvYs8TrzgTasoOe/MkFZ9FZ31XRL4loyPU9gid06ENA+Yc9xyRssUtjNsQfCNV+enSzbMBr4FvWmSoJNoVbQyi3tj13emflBqP+rROpeG7mgol+aP49z3RW56wOS0dhFqg8AXRyp1QLld/rJXzb3UH5l7WTXhX7DCuySezxhEyi1lGw== ftpcom(a)ftp.snt.utwente.nl
Then I will try to set-up our scripting in order to get the mirror in sync as soon as possible.
Kind regards,
Erwin Bronkhorst
FTPCom Studenten Net Twente
Van: Shlomi Zidmi <szidmi(a)redhat.com>
Verzonden: dinsdag 19 mei 2020 19:01
Aan: ftpcom(a)snt.utwente.nl
Onderwerp: [ftpcom] oVirt mirror out of sync
Hello from the oVirt infrastructure team,
We have recently noticed you are quite out of sync with mirroring oVirt content (last synced more than a year ago).
If you are still interested in mirroring oVirt, please keep your mirror up to date with our public content.
Otherwise, please let us know and you will be removed from our mirror list:
https://www.ovirt.org/community/get-involved/repository-mirrors.html
Thanks,
Shlomi
------------
oVirt community
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100127)
4 years, 6 months
Build failed in Jenkins: system-mk_mirrors_index-yum #85415
by jenkins＠jenkins.phx.ovirt.org
See <https://jenkins.ovirt.org/job/system-mk_mirrors_index-yum/85415/display/r...>
Changes:
------------------------------------------
Started by upstream project "system-sync_mirrors-ovirt-master-copr-AdvancedVirtualization-el8-x86_64" build number 147
originally caused by:
Started by timer
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <https://jenkins.ovirt.org/job/system-mk_mirrors_index-yum/ws/>
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Pruning obsolete local branches
Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git
> git --version # timeout=10
> git fetch --tags --progress --prune http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* # timeout=10
ERROR: Timeout after 10 minutes
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from http://gerrit.ovirt.org/jenkins.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
at hudson.scm.SCM.checkout(SCM.java:505)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1856)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress --prune http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout:
stderr:
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2430)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2044)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:81)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:569)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to mirrors.phx.ovirt.org
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1788)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
at hudson.remoting.Channel.call(Channel.java:998)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor933.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy90.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:907)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
at hudson.scm.SCM.checkout(SCM.java:505)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1856)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)
ERROR: Error fetching remote repo 'origin'
4 years, 6 months
oVirt 4.4.0 Release is now generally available
by Sandro Bonazzola
oVirt 4.4.0 Release is now generally available
The oVirt Project is excited to announce the general availability of the
oVirt 4.4.0 Release, as of May 20th, 2020
This release unleashes an altogether more powerful and flexible open source
virtualization solution that encompasses hundreds of individual changes and
a wide range of enhancements across the engine, storage, network, user
interface, and analytics, as compared to oVirt 4.3.
Important notes before you install / upgrade
Some of the features included in the oVirt 4.4.0 release require content
that will be available in CentOS Linux 8.2 but cannot be tested on RHEL 8.2
yet due to some incompatibility in the openvswitch package that is shipped
in CentOS Virt SIG, which requires rebuilding openvswitch on top of CentOS
8.2. The cluster switch type OVS is not implemented for CentOS 8 hosts.
Please note that oVirt 4.4 only supports clusters and datacenters with
compatibility version 4.2 and above. If clusters or datacenters are running
with an older compatibility version, you need to upgrade them to at least
4.2 (4.3 is recommended).
Please note that in RHEL 8 / CentOS 8 several devices that worked on EL7
are no longer supported.
For example, megaraid_sas driver is removed. If you use Enterprise Linux 8
hosts you can try to provide the necessary drivers for the deprecated
hardware using the DUD method (See users mailing list thread on this at
https://lists.ovirt.org/archives/list/users@ovirt.org/thread/NDSVUZSESOXE...
)
Installation instructions
For the engine: either use the oVirt appliance or install CentOS Linux 8
minimal by following these steps:
- Install the CentOS Linux 8 image from
http://centos.mirror.garr.it/centos/8.1.1911/isos/x86_64/CentOS-8.1.1911-...
- dnf install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
- dnf update (reboot if needed)
- dnf module enable -y javapackages-tools pki-deps postgresql:12
- dnf install ovirt-engine
- engine-setup
For the nodes:
Either use oVirt Node ISO or:
- Install CentOS Linux 8 from
http://centos.mirror.garr.it/centos/8.1.1911/isos/x86_64/CentOS-8.1.1911-...,
selecting the minimal installation.
- dnf install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
- dnf update (reboot if needed)
- Attach the host to the engine and let it be deployed.
Update instructionsUpdate from oVirt 4.4 Release Candidate
On the engine side and on CentOS hosts, you’ll need to switch from
ovirt44-pre to ovirt44 repositories.
In order to do so, you need to:
1.
dnf remove ovirt-release44-pre
2.
rm -f /etc/yum.repos.d/ovirt-4.4-pre-dependencies.repo
3.
rm -f /etc/yum.repos.d/ovirt-4.4-pre.repo
4.
dnf install https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
5.
dnf update
On the engine side you’ll need to run engine-setup only if you were not
already on the latest release candidate.
On oVirt Node, you’ll need to upgrade with:
1.
Move node to maintenance
2.
dnf install
https://resources.ovirt.org/pub/ovirt-4.4/rpm/el8/noarch/ovirt-node-ng-im...
3.
Reboot
4.
Activate the host
Update from oVirt 4.3
oVirt 4.4 is available only for CentOS 8. In-place upgrades from previous
installations, based on CentOS 7, are not possible. For the engine, use
backup, and restore that into a new engine. Nodes will need to be
reinstalled.
A 4.4 engine can still manage existing 4.3 hosts, but you can’t add new
ones.
For a standalone engine, please refer to upgrade procedure at
https://ovirt.org/documentation/upgrade_guide/#Upgrading_from_4-3
If needed, run ovirt-engine-rename (see engine rename tool documentation at
https://www.ovirt.org/documentation/admin-guide/chap-Utilities.html )
When upgrading hosts:
You need to upgrade one host at a time.
1.
Turn host to maintenance. Virtual machines on that host should migrate
automatically to a different host.
2.
Remove it from the engine
3.
Re-install it with el8 or oVirt Node as per installation instructions
4.
Re-add the host to the engine
Please note that you may see some issues live migrating VMs from el7 to
el8. If you hit such a case, please turn off the vm on el7 host and get it
started on the new el8 host in order to be able to move the next el7 host
to maintenance.
What’s new in oVirt 4.4.0 Release?
-
Hypervisors based on CentOS Linux 8 (rebuilt from award winning RHEL8),
for both oVirt Node and standalone CentOS Linux hosts.
-
Easier network management and configuration flexibility with
NetworkManager.
-
VMs based on a more modern Q35 chipset with legacy SeaBIOS and UEFI
firmware.
-
Support for direct passthrough of local host disks to VMs.
-
Live migration improvements for High Performance guests.
-
New Windows guest tools installer based on WiX framework now moved to
VirtioWin project.
-
Dropped support for cluster level prior to 4.2.
-
Dropped API/SDK v3 support deprecated in past versions.
-
4K block disk support only for file-based storage. iSCSI/FC storage do
not support 4K disks yet.
-
You can export a VM to a data domain.
-
You can edit floating disks.
-
Ansible Runner (ansible-runner) is integrated within the engine,
enabling more detailed monitoring of playbooks executed from the engine.
-
Adding and reinstalling hosts is now completely based on Ansible,
replacing ovirt-host-deploy, which is not used anymore.
-
The OpenStack Neutron Agent cannot be configured by oVirt anymore, it
should be configured by TripleO instead.
This release is available now on x86_64 architecture for:
* Red Hat Enterprise Linux 8.1
* CentOS Linux (or similar) 8.1
This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
for:
* Red Hat Enterprise Linux 8.1
* CentOS Linux (or similar) 8.1
* oVirt Node 4.4 based on CentOS Linux 8.1 (available for x86_64 only)
See the release notes [1] for installation instructions and a list of new
features and bugs fixed.
If you manage more than one oVirt instance, OKD or RDO we also recommend to
try ManageIQ <http://manageiq.org/>.
In such a case, please be sure to take the qc2 image and not the ova image.
Notes:
- oVirt Appliance is already available for CentOS Linux 8
- oVirt Node NG is already available for CentOS Linux 8
Additional Resources:
* Read more about the oVirt 4.4.0 release highlights:
http://www.ovirt.org/release/4.4.0/
* Get more oVirt project updates on Twitter: https://twitter.com/ovirt
* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/
[1] http://www.ovirt.org/release/4.4.0/
[2] http://resources.ovirt.org/pub/ovirt-4.4/iso/
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>
[image: |Our code is open_] <https://www.redhat.com/en/our-code-is-open>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
4 years, 6 months
Re: [ovirt-devel] oVirt and Fedora
by Michal Skrivanek
> On 19 May 2020, at 14:06, Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Mon, May 11, 2020 at 11:45 AM Michal Skrivanek
> <michal.skrivanek(a)redhat.com> wrote:
>>
>>
>>
>>> On 11 May 2020, at 14:49, Neal Gompa <ngompa13(a)gmail.com> wrote:
>>>
>>> On Mon, May 11, 2020 at 8:32 AM Nir Soffer <nsoffer(a)redhat.com> wrote:
>>>>
>>>> On Mon, May 11, 2020 at 2:24 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>>>>
>>>>> As far as the oVirt software keeping up with Fedora, the main problem here has always been that people aren't integrating their software into the distribution itself.
>>
>> it was never a good fit for oVirt to be part of other distributions. We had individual packages part of Fedora in history, but there are things which are hard to accept (like automatically enabling of installed services, UIDs), and overall it’s just too complex, we’re rather a distribution than a simple app on top of base OS.
>>
>
> None of those things are hard to do in Fedora. They're incredibly easy
> to do. I know this because I've gone through this process already
> before.
>
> But fine, let's assume I consider this argument valid. Then there's
> still no reason not to be continually providing support for Fedora as
> an add-on, as you have before.
the reason is mentioned in the original email, the lack of resources to keep actively supporting 3 different platforms.
If you want to provide a helping hand and maintain Fedora infrastructure I don’t think anyone would object
>
>>>>> That's how everything can get tested together. And this comes back to the old bug about fixing vdsm so that it doesn't use /rhev, but instead something FHS-compliant (RHBZ#1369102). Once that is resolved, pretty much the entire stack can go into Fedora. And then you benefit from the Fedora community being able to use, test, and contribute to the oVirt project. As it stands, why would anyone do this for you when you don't even run on the cutting edge platform that feeds into Red Hat Enterprise Linux?
>>>>
>>>> This was actually fixed a long time ago. With this commit:
>>>> https://github.com/oVirt/vdsm/commit/67ba9c4bc860840d6e103fe604b16f494f60...
>>>>
>>>> You can configure a compatible vdsm that does not use /rhev.
>>>>
>>>> Of course it is not backward compatible, for this we need much more
>>>> work to support live migration
>>>> between old and new vdsm using different data-center configurations.
>>>>
>>>
>>> It'd probably be simpler to just *change* it to an FHS-compatible path
>>> going forward with EL8 and Fedora and set up a migration path there,
>>> but it's a bit late for that... :(
>>
>> It wouldn’t. We always support live migration across several versions (now it’s 4.2-4.4) and it needs to stay the same or youo have to go with arcane code to mangle it back and forth which gets a bit ugly when you consider suspend/resume, snapshots, etc
>>
>
> Erk. At some point you need to bite the bullet though...
it’s about capacity as well, it’s just a matter of someone writing a code which can handle the (long) transition period
Thanks,
michal
4 years, 6 months
Build failed in Jenkins: system-mk_mirrors_index-yum #85291
by jenkins＠jenkins.phx.ovirt.org
See <https://jenkins.ovirt.org/job/system-mk_mirrors_index-yum/85291/display/r...>
Changes:
------------------------------------------
Started by upstream project "system-sync_mirrors-centos-sclo-rh-release-7.6-el7-x86_64" build number 630
originally caused by:
Started by timer
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <https://jenkins.ovirt.org/job/system-mk_mirrors_index-yum/ws/>
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Pruning obsolete local branches
Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git
> git --version # timeout=10
> git fetch --tags --progress --prune http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from http://gerrit.ovirt.org/jenkins.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:909)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
at hudson.scm.SCM.checkout(SCM.java:505)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1856)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress --prune http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout:
stderr: fatal: unable to access 'http://gerrit.ovirt.org/jenkins.git/': Could not resolve host: gerrit.ovirt.org; Unknown error
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2430)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2044)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:81)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:569)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:161)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$GitCommandMasterToSlaveCallable.call(RemoteGitImpl.java:154)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to mirrors.phx.ovirt.org
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1788)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
at hudson.remoting.Channel.call(Channel.java:998)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor933.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy90.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:907)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1131)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1167)
at hudson.scm.SCM.checkout(SCM.java:505)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1856)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)
ERROR: Error fetching remote repo 'origin'
4 years, 6 months