- Devel - oVirt List Archives

[ OST Failure Report ] [ oVirt master ] [ 30/07/2017 ] [add_dc]
by Barak Korren 30 Jul '17

30 Jul '17

Test failed: [ add_dc ] Link to suspected patches: https://gerrit.ovirt.org/#/c/79116/39 Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1566/ Link to all logs: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1566/artifact… Error snippet from log: <error> Error: Fault reason is "Operation Failed". Fault detail is "[Internal Engine Error]". HTTP response code is 400. </error> -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

2 1

[engine 4.0->4.1 upgrade] How to effectively test an upgrade
by Tasdik Rahman 29 Jul '17

29 Jul '17

--_000_SG2PR02MB12777351799471CAB9907B89D9BB0SG2PR02MB1277apcp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gdGhlcmUsDQoNCkkgd2FzIHdvbmRlcmluZyBob3cgc2hvdWxkIG9uZSB0ZXN0IGFmdGVy IHVwZ3JhZGluZyB0aGUgc3lzdGVtLiBUaGUgdmVyc2lvbnMgSSBhbSBhdCBoYW5kIHJpZ2h0IG5v dyBpcyBmcm9tDQoNCiAgKiAgIDQuMCAtPiA0LjENCiAgKiAgIDQuMSAtID4gNC4yDQoNCkJ1dCBJ IGFtIGd1ZXNzaW5nIHRoZSB0ZXN0aW5nIHNob3VsZCBub3QgZGlmZmVyIG11Y2ggYmV0d2VlbiB0 aGUgZGlmZmVyZW50IHZlcnNpb25zLg0KDQpTdWdnZXN0aW9ucyB3b3VsZCBiZSBhcHByZWNpYXRl ZC4NCg0KVGhhbmtzLA0KVGFzZGlrDQo= --_000_SG2PR02MB12777351799471CAB9907B89D9BB0SG2PR02MB1277apcp_ Content-Type: text/html; charset="utf-8" Content-ID: <0A9BD53C31B67E4E9D2478F132F62BD4(a)apcprd02.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHRleHQ9IiMwMDAwMDAi IGJnY29sb3I9IiNGRkZGRkYiPg0KPHA+SGVsbG8gdGhlcmUsIDxicj4NCjxicj4NCkkgd2FzIHdv bmRlcmluZyBob3cgc2hvdWxkIG9uZSB0ZXN0IGFmdGVyIHVwZ3JhZGluZyB0aGUgc3lzdGVtLiBU aGUgdmVyc2lvbnMgSSBhbSBhdCBoYW5kIHJpZ2h0IG5vdyBpcyBmcm9tPGJyPg0KPC9wPg0KPHVs Pg0KPGxpPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDM2LCA0MSwgNDYpOyBmb250LWZhbWlseToN CiAgICAgICAgICAtYXBwbGUtc3lzdGVtLCBzeXN0ZW0tdWksICZxdW90O1NlZ29lIFVJJnF1b3Q7 LCBIZWx2ZXRpY2EsDQogICAgICAgICAgQXJpYWwsIHNhbnMtc2VyaWYsICZxdW90O0FwcGxlIENv bG9yIEVtb2ppJnF1b3Q7LCAmcXVvdDtTZWdvZQ0KICAgICAgICAgIFVJIEVtb2ppJnF1b3Q7LCAm cXVvdDtTZWdvZSBVSSBTeW1ib2wmcXVvdDs7IGZvbnQtc2l6ZTogMTRweDsNCiAgICAgICAgICBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsNCiAgICAg ICAgICBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOw0KICAg ICAgICAgIGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0 YXJ0Ow0KICAgICAgICAgIHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOw0KICAgICAgICAgIHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsNCiAgICAgICAgICBiYWNrZ3JvdW5k LWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IHRleHQtZGVjb3JhdGlvbi1zdHlsZToNCiAgICAg ICAgICBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7IGRpc3BsYXk6IGlu bGluZQ0KICAgICAgICAgICFpbXBvcnRhbnQ7IGZsb2F0OiBub25lOyI+NC4wDQogLSZndDsgNC4x PC9zcGFuPiA8L2xpPjxsaT48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9u dC1mYW1pbHk6DQogICAgICAgICAgLWFwcGxlLXN5c3RlbSwgc3lzdGVtLXVpLCAmcXVvdDtTZWdv ZSBVSSZxdW90OywgSGVsdmV0aWNhLA0KICAgICAgICAgIEFyaWFsLCBzYW5zLXNlcmlmLCAmcXVv dDtBcHBsZSBDb2xvciBFbW9qaSZxdW90OywgJnF1b3Q7U2Vnb2UNCiAgICAgICAgICBVSSBFbW9q aSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7OyBmb250LXNpemU6IDE0cHg7DQog ICAgICAgICAgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7DQogICAgICAgICAgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsNCiAgICAgICAgICBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0 LWFsaWduOiBzdGFydDsNCiAgICAgICAgICB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsNCiAgICAgICAgICB3aWRvd3M6IDI7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7DQogICAgICAgICAg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyB0ZXh0LWRlY29yYXRpb24tc3R5 bGU6DQogICAgICAgICAgaW5pdGlhbDsgdGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsOyBk aXNwbGF5OiBpbmxpbmUNCiAgICAgICAgICAhaW1wb3J0YW50OyBmbG9hdDogbm9uZTsiPjQuMQ0K IC0gJmd0OyA0LjI8L3NwYW4+IDwvbGk+PC91bD4NCjxwPkJ1dCBJIGFtIGd1ZXNzaW5nIHRoZSB0 ZXN0aW5nIHNob3VsZCBub3QgZGlmZmVyIG11Y2ggYmV0d2VlbiB0aGUgZGlmZmVyZW50IHZlcnNp b25zLg0KPGJyPg0KPGJyPg0KU3VnZ2VzdGlvbnMgd291bGQgYmUgYXBwcmVjaWF0ZWQuPGJyPg0K PGJyPg0KVGhhbmtzLCA8YnI+DQpUYXNkaWs8YnI+DQo8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SG2PR02MB12777351799471CAB9907B89D9BB0SG2PR02MB1277apcp_--

3 2

[VDSM] Fedora 26 build in travis
by Nir Soffer 29 Jul '17

29 Jul '17

Hi all, We have now Fedora 26 build in travis. Everything works except blivet, see https://bugzilla.redhat.com/1450607 I removed the Fedora 24 dockerfile from master, we don't use this image for some time. Please review: https://gerrit.ovirt.org/#/q/topic:dockerfile+is:open Thanks, Nir

1 0

Quartz -> ManagedScheduledExecutorService
by Ravi Shankar Nori 27 Jul '17

27 Jul '17

Hi, We have been working on Threading related changes on engine to move from java ExecutorServices to JBoss ManagedExecutorServices. The dependency on quartz for running scheduled jobs is being phased out and we are moving to scheduling jobs using JBoss ManagedScheduledExecutorService. As far as development goes it should be pretty straight forward. Inject the JBoss ManagedScheduledExecutorService @Inject @ThreadPools(ThreadPools.ThreadPoolType.EngineScheduledThreadPool) private ManagedScheduledExecutorService executorService; and then in PostConstruct you can schedule the job on the executor service using a cron expression. @PostConstruct private void init() { executor.schedule(this::cleanup, new EngineCronTrigger(cronExpression)); } To schedule a job to execute at regular intervals you can use the scheduleWithFixedDelay @PostConstruct private void init() { scheduledExecutorService.scheduleWithFixedDelay(this::cleanExpiredUsersSessions, 1, 1, TimeUnit.MINUTES); } If you have any questions please feel free to contact me or Martin Perina ( mperina(a)redhat.com) Thanks Ravi

1 0

Re: [ovirt-devel] [ovirt-users] Help get oVirt's add featured on Stack Overflow
by Karli Sjöberg 27 Jul '17

27 Jul '17

1 0

Help get oVirt's add featured on Stack Overflow
by Allon Mureinik 27 Jul '17

27 Jul '17

Hi lists, Thanks to Eldan, we have a community ad for oVirt proposed on Stack Overflow [1]. Now, we need some upvotes (current threshold is 6) before SO starts serving it. Have a SO account? Want to help? Just drop by and upvote. Have a great weekend, Allon [1] https://meta.stackoverflow.com/a/351453/2422776

3 4

[ACTION REQUIRED] upgrade to otopi-1.7.1
by Yedidyah Bar David 26 Jul '17

26 Jul '17

Hi all, Please update otopi on your development machines to 1.7.1+. It should be available from the nightly master snapshot. A patch to make the engine require it [1] will soon be merged. Soon after that I hope to get merged several patches, first one is [2], that will break engine-setup if you do not have otopi-1.7.1+. If you do not upgrade by then, 'engine-setup' will fail silently. If you run it as 'OTOPI_DEBUG=1 engine-setup', you will get: _toposortBuildSequence failed: Cyclic dependencies found ('FATAL Internal error (main): Cyclic dependencies found',) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/__main__.py", line 88, in main installer.execute() File "/usr/lib/python2.7/site-packages/otopi/main.py", line 156, in execute self.context.buildSequence() File "/usr/lib/python2.7/site-packages/otopi/context.py", line 665, in buildSequence self._sequence = self._toposortBuildSequence() File "/usr/lib/python2.7/site-packages/otopi/context.py", line 624, in _toposortBuildSequence raise RuntimeError(_('Cyclic dependencies found')) RuntimeError: Cyclic dependencies found Best, [1] https://gerrit.ovirt.org/79799 [2] https://gerrit.ovirt.org/#/c/79567/4 -- Didi

1 0

status update: consuming the BLOCK_THRESHOLD event from libvirt (rhbz#1181665)
by Francesco Romani 26 Jul '17

26 Jul '17

Hi all, With libvirt 3.2.0 and onwards, it seems we have now the tools to solve https://bugzilla.redhat.com/show_bug.cgi?id=1181665 and eventually get rid of the disk polling we do. This change is expected to have huge impact on performance, so I'm working on it. I had plans for a comprehensive refactoring in this area, but looks like a solution backportable for 4.1.z is appealing, so I started with this first, saving the refactoring (which I still very much want) for later. So, quick summary: libvirt >= 3.2.0 allows to set a threshold to any node in the backing chain of each drive of a VM (https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainSetBlockThres…) and fire one event exactly once when that threshold is crossed. The event needs to be explicitely rearmed after. This is exactly what we need to get rid of polling in the steady state, so far so good. The problem is: we can't use this for some important flows we have, and which involve usage of disks not (yet) attached to a given VM. Possibly affected flows: - live storage migration: we use flags = (libvirt.VIR_DOMAIN_BLOCK_COPY_SHALLOW | libvirt.VIR_DOMAIN_BLOCK_COPY_REUSE_EXT | VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB) meaning that Vdsm is in charge of handling the volume - snapshots: we use snapFlags = (libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT | libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_NO_METADATA) (same meaning as above) - live merge: should be OK (according to a glance at the source and a chat with Adam). So looks like we will need to bridge this gap. So we can still use the BLOCK_THRESHOLD event for steady state, and avoid polling in the vast majority of the cases. With "steady state" I mean that the VM is running, with no administration (snapshot, live merge, live storage migration...) operation in progress. I think it is fair to assume that VMs are in this state the vast majority of the time. For the very important cases on which we cannot depend on events, we can fall back to polling, but in a smarter way: instead of polling everything every 2s, let's just poll just the drives involved in the ongoing operations. Those should be far less of the total amount of drives, and for a far shorter time than today, so polling should be practical. Since the event fires once, we will need to rearm it only if the operation is ongoing, and only just before to start it (both conditions easy to check) We can disable the polling on completion, or on error. This per se is easy, but we will need a careful review of the flows, and perhaps some safety nets in place. Anyway, should we miss to disable the polling, we will "just" have some overhead. On recovery, we will need to make sure to rearm all the relevant events, but we can just plug in the recovery we must do already, so this should be easy as well. So it seems to me this could fly and we can actually have the performance benefits of events. However, due to the fact that we need to review some existing and delicate flows, I think we should still keep the current polling code around for the next release. I believe the best route is: 1. offer the new event-based code for 4.2, keep the polling around. Default to events for performance 2. remove the polling completely in 4.3 I'm currently working on the patches here: https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:w… Even though the basics are in place, I don't think they are ready for review yet. Comments welcome, as usual. -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

4 6

Nested virtualization on Fedora 26
by Jakub Niedermertl 25 Jul '17

25 Jul '17

Hi all, in case someone else is also struggling with nested virtualization on Fedora 26, here is a bug [1] tracking the problem including a workaround. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1474874 Jakub

2 1

Jenkins was restarted
by Barak Korren 25 Jul '17

25 Jul '17

Jenkins ran out of file descriptors so we had to restart it to bump the number. Jobs should be running jobs already but the UI will probably take 30-40 minutes to become available. Issues seem to have started around 15:00 UTC yesterday (18:00 IST) so you may need to re-trigger jobs for patches submitted since then. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

1 0