- Devel - oVirt List Archives

oVirt CI now supports Fedora 28
by Barak Korren 02 May '18

02 May '18

Since Fedora 28 was released yesterday, we've added support for it in the oVirt CI system. To use Fedora 28 just use 'fc28' as you would for other Fedora versions in the CI YAML files and/or file extensions in the 'automation/' directory. The synchronisation for our local mirror is ongoing at this time, so until it is done, the upstream Fedora mirrors will be used, this can cause some breakage. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

1 0

Broken deps wihle testing master? Here some info
by Sandro Bonazzola 02 May '18

02 May '18

Hi, ovirt-release-master enables testing repos from CentOS. Testing repos are now switching to CentOS 7.5.1804 so you now need to enable also the CR repo when testing master on CentOS. CentOS 7.5 should be released this week or in worst case next week, so this is just a temporary issue while 7.5 is being rolled out. oVirt release 4.2 uses stable repos and is not affected by this temporary glitch. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

1 0

Re: [ovirt-devel] default maintainers plugin for other projects
by Barak Korren 02 May '18

02 May '18

(adding devel because this might be interesting for others). On 1 May 2018 at 21:16, Greg Sheremeta <gshereme(a)redhat.com> wrote: > How would I get this plugin added to ovirt-engine-dashboard and > ovirt-engine-node* ? > Its already available for all projects in gerrit.ovirt.org. > And then how would I configure it? (Add myself as a default, at least) > Two ways: With the GUI: ----------------- In Gerrit UI go to: Admin -> Projects -> (Old UI) -> (Your project) -> Reviewers (from top bar) Fill in filter (A file glob pattern - can be '*') and reviewer (An email address ora gerrit group ) and click "Add". Don't forget to switch back to new UI from the bottom right link. >From the command line ------------------------------- In a Git clone of the relevant project do: # git fetch origin refs/meta/config:meta-config # git checkout meta-config Then you can edit the 'reviewers.config' file (Make it if it isn't there) and put in something like the following: [filter "*"] reviewer = jenkins-maintainers reviewer = dron(a)redhat.com Once you're done with it commit the change and push it with: # git push -u origin meta-config refs/meta/config Since we have '-u' there, the next time around you change the 'meta-config' branch you can just do: # git push -u origin And that's about it. One thing to note - every project has a '<project-name>-maintainers' group, so its useful to add it it default. > ---------- Forwarded message ---------- > From: Roy Golan <rgolan(a)redhat.com> > Date: Mon, Jun 19, 2017 at 7:17 AM > Subject: Re: [ovirt-devel] [ENGINE][ACTION_NEEDED] - default maintainers, > per path > To: devel <devel(a)ovirt.org> > > > The patch is now merged and the it should start working immediately. For > anyone who is listed as a default reviewer I suggest to test it with a test > patch by some other submitter. (except for those who used groups of course) > > Thanks everyone for the cooperation on this. > > > On Mon, May 29, 2017 at 2:24 PM Roy Golan <rgolan(a)redhat.com> wrote: > >> Hi all, >> >> Some time ago the infra team enabled *gerrit default reviewer plugin* >> which you probably noticed if you logged in to gerrit. >> >> What we can do is for example set the stable branch maintainers per >> branch automatically: >> >> [filter "branch:ovirt-engine-4.1"] >> reviewer = stableBranchMaintainersGroup >> >> Put people based on path: >> >> [filter "branch:master file:^frontend/.*"] >> reviewer = j.r.r.t(a)shire.me >> >> >> >> *Action Needed:* >> Nominate yourself, or others, by amending this patch online [1]. Once >> this patch is fully acked and agreed we will merge it. If something can't >> get consensus we will defer it from the patch till maintainers agree. >> >> [1] https://gerrit.ovirt.org/#/c/77488/ >> >> >> >> >> > > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > > -- > > GREG SHEREMETA > > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > > Red Hat NA > > <https://www.redhat.com/> > > gshereme(a)redhat.com IRC: gshereme > <https://red.ht/sig> > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > > -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

1 0

OST Failure - Weekly update [/04/2018-20/04/2018]
by Dafna Ron 30 Apr '18

30 Apr '18

Hi, I wanted to give a short status on this week's failures and OST current status. I am glad to report that the issue with CQ alerts was resolved thanks to Barak and Evgheni. You can read more about the issue and how it was resolved here: https://ovirt-jira.atlassian.net/browse/OVIRT-1974 Currently we have one on-going possible regression which was reported to the list and to Arik. the change reported: https://gerrit.ovirt.org/#/c/89852/ - examples: upload ova as a virtual machine template. you can view the details in this Jira: https://ovirt-jira.atlassian.net/browse/OFT-648 The majority of issues we had this week were failed-build artifacts for fc27. There were two different cases, one was reported to Francesco who was already working on a fix to the issue and the second started and resolved during the evening/night of Apr 26-27. You can see the Jira to these two issues here: https://ovirt-jira.atlassian.net/browse/OFT-605 https://ovirt-jira.atlassian.net/browse/OFT-612 There was an infra issue with Mirrors not being available for a few minutes. the issue was momentarily and was resolved on its own. https://ovirt-jira.atlassian.net/browse/OFT-606 *Below you can see the chart for this week's resolved issues but cause of failure:**Code* = regression of working components/functionalities *Infra* = infrastructure/OST Infrastructure/Lago related issues/Power outages *OST Tests* = package related issues, failed build artifacts *Below is a chart showing failures by suite type: * *Below is a chart showing failures by version type: * *Below you can see the number of reported failures by resolution status:* Thanks, Dafna

4 5

Update: HC suites failing for 3 weeks ( was: [OST][HC] HE fails to deploy )
by Eyal Edri 30 Apr '18

30 Apr '18

FYI, I've disabled the 4.2 and master HC suites nightly run on CI as they are constantly failing for almost 3 weeks and spamming the mailing lists. I think this should get higher priority for a fix if we want it to provide any value, Work can continue using the manual jobs or via check-patch. On Mon, Apr 16, 2018 at 10:56 AM, Gal Ben Haim <gbenhaim(a)redhat.com> wrote: > Any update on https://gerrit.ovirt.org/#/c/88887/ ? > The HC suites still failing and it's hard to understand why without the > logs from the engine VM. > > On Sat, Apr 7, 2018 at 7:19 AM, Sahina Bose <sabose(a)redhat.com> wrote: > >> >> >> On Fri, Apr 6, 2018 at 1:10 PM, Simone Tiraboschi <stirabos(a)redhat.com> >> wrote: >> >>> >>> >>> On Fri, Apr 6, 2018 at 9:28 AM, Sahina Bose <sabose(a)redhat.com> wrote: >>> >>>> 2018-04-05 20:46:52,773-0400 INFO otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:100 TASK [Get local VM IP] >>>> 2018-04-05 20:55:28,217-0400 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 {u'_ansible_parsed': True, u'stderr_lines': [], u'cmd': u"virsh -r net-dhcp-leases default | grep -i 00:16:3e:24:d3:63 | awk '{ print $5 }' | cut -f1 -d'/'", u'end': u'2018-04-05 20:55:28.046320', u'_ansible_no_log': False, u'stdout': u'', u'changed': True, u'invocation': {u'module_args': {u'warn': True, u'executable': None, u'_uses_shell': True, u'_raw_params': u"virsh -r net-dhcp-leases default | grep -i 00:16:3e:24:d3:63 | awk '{ print $5 }' | cut -f1 -d'/'", u'removes': None, u'creates': None, u'chdir': None, u'stdin': None}}, u'start': u'2018-04-05 20:55:28.000470', u'attempts': 50, u'stderr': u'', u'rc': 0, u'delta': u'0:00:00.045850', u'stdout_lines': []} >>>> 2018-04-05 20:55:28,318-0400 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:98 fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "virsh -r net-dhcp-leases default | grep -i 00:16:3e:24:d3:63 | awk '{ print $5 }' | cut -f1 -d'/'", "delta": "0:00:00.045850", "end": "2018-04-05 20:55:28.046320", "rc": 0, "start": "2018-04-05 20:55:28.000470", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} >>>> >>>> Both the 4.2 and master suites are failing on getting local VM IP. >>>> Any idea what changed or if I have to change the test? >>>> >>>> thanks! >>>> >>> >>> Hi Sahina, >>> 4.2 and master suite non HC are correctly running this morning. >>> http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovi >>> rt-system-tests_he-basic-ansible-suite-master/146/ >>> http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovi >>> rt-system-tests_he-basic-ansible-suite-4.2/76/ >>> >>> I'll try to check the difference with HC suites. >>> >>> Are you using more than one subnet in the HC suites? >>> >> >> No, I'm not. And we havent's changed anything related to network in the >> test suite. >> >> >> > > > -- > *GAL bEN HAIM* > RHV DEVOPS > -- Eyal edri MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

3 8

Mailing-Lists upgrade
by Marc Dequènes (Duck) 27 Apr '18

27 Apr '18

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: multipart/mixed; boundary="AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv"; protected-headers="v1" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com> To: oVirt Infra <infra(a)ovirt.org>, users <users(a)ovirt.org>, devel <devel(a)ovirt.org> Message-ID: <c5c71fce-0290-e97a-ddd0-eab0e6fccea4(a)redhat.com> Subject: Mailing-Lists upgrade --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Quack, On behalf of the oVirt infra team, I'd like to announce the current Mailing-Lists system is going to be upgraded to a brand new Mailman 3 installation on Monday during the slot 11:00-12:00 JST. It should not take a full hour to migrate as we already made incremental synchronization with the current system but better keep some margin. The system will then take over delivery of the mails but might be a bit slow at first as it needs to reindex all the archived mails (which might take a few hours). To manage your subscriptions and delivery settings you can do this easily on the much nicer web interface (https://lists.ovirt.org) There is a notion of account so you don't need to login separately for each ML.= You can Sign In using Fedora, GitHub or Google or create a local account if you prefer. Please keep in mind signing in with a different method would create separate accounts (which cannot be merged at the moment). But you can easily link your account to other authentication methods in your settings (click on you name in the up-right corner -> Account -> Account Connections). As for the original mail archives, because the previous system did not have stable URLs, we cannot create mappings to the new pages. We decided to keep the old archives around on the same URL (/pipermail), so the Internet links would still work fine. Hope you'd be happy with the new system. \_o< --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv-- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlmwx0MACgkQVen596wc RD9LTQ/+LtUncsq9K8D/LX8wqUTd6VyPwAD5UnAk5c3H/2tmyVA0u7FIfhEyPsXs Z//LE9FEneTDqDVRi1Dw9I54K0ZwxPBemi71dXfwgBI7Ay0ezkbLWrA168Mt9spE tHAODEuxPt2to2aqaS4ujogrkp/gvEP8ILoxPEqoTPCJ/eDTPAu/I1a2JzjMPK3n 2BBS6D8z0TLAf7w1n72TsgX2QzJW57ig/0HELyjvat2/K8V3HSrkwiKlsdULQDWe zB+aMde7r6UoyVKHqlu4asTl2tU/lGZ+e31Hd9Bnx1/oZOJdzslGOhEo9Qoz6763 AHWU9LKiK4NtxYHj2UQTWhndr8PiTtTmR73eIDmkb0cuRXxzjl9VQbwYJ0Kbrmfp attTqpc2CnEojTNXUUNSmNxotZoYXZiX8ZvjPfSgRVr15TUYujzlOfG+lUynbQMV 9rQ9/m58wgwYUymMpOIsRGaIcAKzjm+WpuuVnO+bS2AfmcBkGMQRoIhfV+3SkS8q kT9cDXgcDZOzVFcnZZB4EjbycMcPgZDcoHxU88VdYH+jFJYvvb21esgswVF/wJ2Z uEI/chp4+ADaQhl8ehZNWMSZq125v6SeirPhBNgLG7zFVZI1S9Tm/6qFmH+ajQY7 nCk1X9HZlB1ubex1X+HibRz9QKOilkMgkADyJ4yMDckwYj93sx0= =l6uN -----END PGP SIGNATURE----- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq--

2 4

[ OST Failure Report ] [ oVirt Master (ovirt-engine-sdk) ] [ 27-04-2018 ] [ 004_basic_sanity.verify_vm_import ]
by Dafna Ron 27 Apr '18

27 Apr '18

Hi, CQ reported a failure for test 004_basic_sanity.verify_vm_import on basic suite. It seems to me that its related to the reported change. can you please have a look? *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/89852/ <https://gerrit.ovirt.org/#/c/89852/> - examples: upload ova as a virtual machine template Link to Job:* * http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7166/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7166/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7166/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7166/artifact…>(Relevant) error snippet from the log: <error>vdsm: * *2018-04-27 10:26:03,131-0400 INFO (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call Host.dumpxmls succeeded in 0.00 seconds (__init__:311)2018-04-27 10:26:04,825-0400 DEBUG (tasks/8) [root] FAILED: <err> = "virt-sparsify: error: libguestfs error: guestfs_launch failed.\nThis usually means the libguestfs appliance failed to start or crashed.\nDo:\n export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1\nand run the command again. For further information, read:\n http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs\nYou <http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs\nYou> can also run 'libguestfs-test-tool' and post the *complete* output\ninto a bug report or message to the libguestfs mailing list.\n\nIf reporting bugs, run virt-sparsify with debugging enabled and include the \ncomplete output:\n\n virt-sparsify -v -x [...]\n"; <rc> = 1 (commands:87)2018-04-27 10:26:04,829-0400 INFO (tasks/8) [storage.SANLock] Releasing Lease(name='ee91b001-53e4-42b0-9dc1-3a24e5e2b273', path=u'/rhev/data-center/mnt/192.168.200.4:_exports_nfs_share1/c4befad8-ac1e-4cf7-929e-8c26e3a12935/images/46fd673b-4e94-4bc5-aab3-f7af16f11e19/ee91b001-53e4-42b0-9dc1-3a24e5e2b273.lease', offset=0) (clusterlock:435)2018-04-27 10:26:04,835-0400 INFO (tasks/8) [storage.SANLock] Successfully released Lease(name='ee91b001-53e4-42b0-9dc1-3a24e5e2b273', path=u'/rhev/data-center/mnt/192.168.200.4:_exports_nfs_share1/c4befad8-ac1e-4cf7-929e-8c26e3a12935/images/46fd673b-4e94-4bc5-aab3-f7af16f11e19/ee91b001-53e4-42b0-9dc1-3a24e5e2b273.lease', offset=0) (clusterlock:444)2018-04-27 10:26:04,835-0400 ERROR (tasks/8) [root] Job u'f7cc21f1-26fa-430a-93d0-671b402613d1' failed (jobs:221)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/jobs.py", line 157, in run self._run() File "/usr/lib/python2.7/site-packages/vdsm/storage/sdm/api/sparsify_volume.py", line 56, in _run virtsparsify.sparsify_inplace(self._vol_info.path) File "/usr/lib/python2.7/site-packages/vdsm/virtsparsify.py", line 71, in sparsify_inplace raise cmdutils.Error(cmd, rc, out, err)Error: Command ['/usr/bin/virt-sparsify', '--machine-readable', '--in-place', u'/rhev/data-center/mnt/192.168.200engine: 2018-04-27 10:16:40,016-04 ERROR [org.ovirt.engine.core.bll.storage.domain.AttachStorageDomainToPoolCommand] (default task-9) [] An error occurred while fetching unregistered disks from Storage Domain id 'f25de789-f7ce-4b7a-9e92-156bae627b9c'{"jsonrpc": "2.0", "id": "38e21a74-88e9-4f1b-a4bf-8ba61f6a0438", "error": {"message": "Image does not exist in domain: u'image=79a81745-1140-4ba8-aa6b-16ab7820df5e, domain=9729b818-49e6-4ac6-b7a6-5d634bb06a83'", "code": 268}}^@2018-04-27 10:28:00,286-04 DEBUG [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker] (ResponseWorker) [] Message received: {"jsonrpc": "2.0", "id": "38e21a74-88e9-4f1b-a4bf-8ba61f6a0438", "error": {"message": "Image does not exist in domain: u'image=79a81745-1140-4ba8-aa6b-16ab7820df5e, domain=9729b818-49e6-4ac6-b7a6-5d634bb06a83'", "code": 268}}2018-04-27 10:28:00,296-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-12) [1d9c39cd] EVENT_ID: IRS_BROKER_COMMAND_FAILURE(10,803), VDSM command DeleteImageGroupVDS failed: Image does not exist in domain: u'image=79a81745-1140-4ba8-aa6b-16ab7820df5e, domain=9729b818-49e6-4ac6-b7a6-5d634bb06a83'2018-04-27 10:28:00,296-04 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-12) [1d9c39cd] Command 'DeleteImageGroupVDSCommand( DeleteImageGroupVDSCommandParameters:{storagePoolId='42724c3b-3d09-4c1d-a716-56758c9ba2e3', ignoreFailoverLimit='false', storageDomainId='9729b818-49e6-4ac6-b7a6-5d634bb06a83', imageGroupId='79a81745-1140-4ba8-aa6b-16ab7820df5e', postZeros='false', discard='true', forceDelete='false'})' execution failed: IRSGenericException: IRSErrorException: Image does not exist in domain: u'image=79a81745-1140-4ba8-aa6b-16ab7820df5e, domain=9729b818-49e6-4ac6-b7a6-5d634bb06a83'2018-04-27 10:28:00,296-04 DEBUG [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-12) [1d9c39cd] Exception: org.ovirt.engine.core.vdsbroker.irsbroker.IrsOperationFailedNoFailoverException: IRSGenericException: IRSErrorException: Image does not exist in domain: u'image=79a81745-1140-4ba8-aa6b-16ab7820df5e, domain=9729b818-49e6-4ac6-b7a6-5d634bb06a83' at org.ovirt.engine.core.vdsbroker.vdsbroker.BrokerCommandBase.proceedProxyReturnValue(BrokerCommandBase.java:180) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand.executeIrsBrokerCommand(DeleteImageGroupVDSCommand.java:30) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand.lambda$executeVDSCommand$0(IrsBrokerCommand.java:98) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxy.runInControlledConcurrency(IrsProxy.java:274) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand.executeVDSCommand(IrsBrokerCommand.java:95) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:398) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown Source) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source) [:1.8.0_161] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source) [:1.8.0_161] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown Source) [vdsbroker.jar:] at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runVdsCommand(CommandBase.java:2046) [bll.jar:] at org.ovirt.engine.core.bll.storage.disk.image.RemoveImageCommand.performDeleteImageVdsmOperation(RemoveImageCommand.java:310) [bll.jar:] at org.ovirt.engine.core.bll.storage.disk.image.RemoveImageCommand.executeCommand(RemoveImageCommand.java:112) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1133) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1286) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1935) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1346) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:400) [bll.jar:] at org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:450) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:432) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:638) [bll.jar:] at sun.reflect.GeneratedMethodAccessor551.invoke(Unknown Source) [:1.8.0_161] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_161] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509):2018-04-27 10:28:00,358-04 INFO [org.ovirt.engine.core.bll.exportimport.ImportVmCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-12) [] Lock freed to object 'EngineLock:{exclusiveLocks='[2cf61dee-c89c-469a-8ab8-54aebd0ab875=VM, imported_vm=VM_NAME]', sharedLocks='[5e0b3417-5e0d-4f98-a3cb-1a78445de946=REMOTE_VM]'}'2018-04-27 10:28:00,372-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-12) [] EVENT_ID: IMPORTEXPORT_IMPORT_VM_FAILED(1,153), Failed to import Vm imported_vm to Data Center test-dc, Cluster test-cluster</error>*

1 0

Fwd: [CentOS-devel] CentOS 7.4.1708 CR Available in CBS
by Sandro Bonazzola 27 Apr '18

27 Apr '18

FYI, CentOS 7.5 beta is available in CR repos. I'm going to build qemu-kvm-ev for it in CBS but it will be published to release repo only when CentOS 7.5 will go GA. Please note that test repos will be updated with this build so in order to use test repo you'll need CR repo enabled. ---------- Forwarded message ---------- From: Brian Stinson <brian(a)bstinson.com> Date: 2018-04-26 23:16 GMT+02:00 Subject: [CentOS-devel] CentOS 7.4.1708 CR Available in CBS To: centos-devel(a)centos.org Hi Folks, The CR (https://wiki.centos.org/AdditionalResources/Repositories/CR) repository was released earlier today. We have regenerated all the CentOS 7 buildroots in CBS so you can build against the content that will make it into the next point-release of CentOS Linux. Machines in ci.centos.org are available with CR as well so you may continue your testing. As we discussed earlier (https://lists.centos.org/pipermail/centos-devel/2018-April/016627.html) we are currently in Point-release Freeze which means anything tagged for release will *NOT* get pushed out to mirror.centos.org and we will be holding new push requests until we have a GA point-release. If there are any questions please find us here or in #centos-devel on Freenode. Cheers! -- Brian Stinson _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org https://lists.centos.org/mailman/listinfo/centos-devel -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

1 0

Changing unit labels from GB, MB, KB to GiB, MiB, KiB
by Andrej Krejcir 26 Apr '18

26 Apr '18

Hi, In the ovirt-engine UI, we use units KB, MB, GB with the meaning of powers of 1024 bytes, instead of powers of 1000. Some time ago, there was a bug[1] that has changed some of the GB labels to GiB, but not in all places. This causes inconsistent messages in the UI, where one part of a sentence uses GB and the other GiB. To make it consistent, I have posted patches[2] that change unit labels in other places as well. This change touches strings from different parts of the project, so I'm sending this email to let you know about it. Feel free to check the patches or comment if the change is correct. Andrej [1] - https://bugzilla.redhat.com/1535714 [2] - https://gerrit.ovirt.org/#/q/project:ovirt-engine+topic:unit-relabel

2 1

gerrit service restart
by Evgheni Dereveanchin 26 Apr '18

26 Apr '18

Hi everyone, As you may have noticed, Gerrit is slow to respond today. I will restart the service in a few minutes to address that so if you get some failures while trying to fetch/push/review patches please re-try in a few minutes. -- Regards, Evgheni Dereveanchin

1 1