March 2018 - Devel - oVirt List Archives

Terraform provider for oVirt
by Sandro Bonazzola 15 May '18

15 May '18

Hi, just following up from twitter[1], if any developer within oVirt knows about Terraform, there's interest on their side for collaboration developing a provider. For more info, see the github issue: https://github.com/hashicorp/terraform/issues/16150 [1] https://twitter.com/jepeltw/status/955647436931858432 -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 7

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

28 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

Re: [ovirt-devel] [virt-tools-list] Project for profiles and defaults for libvirt domains
by Martin Kletzander 08 Apr '18

08 Apr '18

--ieNMXl1Fr3cevapt Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ I fixed up ovirt-devel(a)redhat.com to be devel(a)ovirt.org since the former is deprecated. I'm also not trimming down much of the reply so that they can get the whole picture. Sorry for the confusion ] On Tue, Mar 20, 2018 at 03:10:12PM +0000, Daniel P. Berrang=E9 wrote: >On Tue, Mar 20, 2018 at 03:20:31PM +0100, Martin Kletzander wrote: >> 1) Default devices/values >> >> Libvirt itself must default to whatever values there were before any >> particular element was introduced due to the fact that it strives to >> keep the guest ABI stable. That means, for example, that it can't just >> add -vmcoreinfo option (for KASLR support) or magically add the pvpanic >> device to all QEMU machines, even though it would be useful, as that >> would change the guest ABI. >> >> For default values this is even more obvious. Let's say someone figures >> out some "pretty good" default values for various HyperV enlightenment >> feature tunables. Libvirt can't magically change them, but each one of >> the projects building on top of it doesn't want to keep that list >> updated and take care of setting them in every new XML. Some projects >> don't even expose those to the end user as a knob, while others might. > >This gets very tricky, very fast. > >Lets say that you have an initial good set of hyperv config >tunables. Now sometime passes and it is decided that there is a >different, better set of config tunables. If the module that is >providing this policy to apps like OpenStack just updates itself >to provide this new policy, this can cause problems with the >existing deployed applications in a number of ways. > >First the new config probably depends on specific versions of >libvirt and QEMU, and you can't mandate to consuming apps which >versions they must be using. So you need a matrix of libvirt + >QEMU + config option settings. > >Even if you have the matching libvirt & QEMU versions, it is not >safe to assume the application will want to use the new policy. >An application may need live migration compatibility with older >versions. Or it may need to retain guaranteed ABI compatibility >with the way the VM was previously launched and be using transient >guests, generating the XML fresh each time. > >The application will have knowledge about when it wants to use new >vs old hyperv tunable policy, but exposing that to your policy module >is very tricky because it is inherantly application specific logic >largely determined by the way the application code is written. > The idea was for updating XML based on policy, which is something you want for new machines. You should then keep the XML per domain and only do changes to if requested by the user or when libvirt fills in new values in a guest ABI compatible fashion. > >> One more thing could be automatically figuring out best values based on >> libosinfo-provided data. >> >> 2) Policies >> >> Lot of the time there are parts of the domain definition that need to be >> added, but nobody really cares about them. Sometimes it's enough to >> have few templates, another time you might want to have a policy >> per-scenario and want to combine them in various ways. For example with >> the data provided by point 1). >> >> For example if you want PCI-Express, you need the q35 machine type, but >> you don't really want to care about the machine type. Or you want to >> use SPICE, but you don't want to care about adding QXL. >> >> What if some of these policies could be specified once (using some DSL >> for example), and used by virtuned to merge them in a unified and >> predictable way? >> >> 3) Abstracting the XML >> >> This is probably just usable for stateless apps, but it might happen >> that some apps don't really want to care about the XML at all. They >> just want an abstract view of the domain, possibly add/remove a device >> and that's it. We could do that as well. I can't really tell how much >> of a demand there is for it, though. > >It is safe to say that applications do not want to touch XML at all. >Any non-trivial application has created an abstraction around XML, >so that they have an API to express what they want, rather than >manipulating of strings to format/parse XML. > Sure, this was just meant to be a question as to whether it's worth pursuing or not. You make a good point on why it is not (at least for existing apps). However, since this was optional, the way this would look without the XML abstraction is that both input and output would be valid domain definitions, ultimately resulting in something similar to virt-xml with the added benefit of applying a policy from a file/string either supplied by the application itself. Whether that policy was taken from a common repository of such knowledge is orthogonal to this idea. Since you would work with the same data, the upgrade could be incremental as you'd only let virtuned fill in values for new options and could slowly move on to using it for some pre-existing ones. None of the previous approaches did this, if I'm not mistaken. Of course it gets more difficult when you need to expose all the bits libvirt does and keep them in sync (as you write below). [...] >If there was something higher level that gets more interesting, >but the hard bit is that you still need a way to get at all the >low level bits becuase a higher level abstracted API will never >cover every niche use case. > Oh, definitely not every, but I see two groups of projects that have a lot in common between themselves and between the groups as well. On the other hand just templating and defaults is something that's easy enough to do that it's not worth outsourcing that into another one's codebase. >> 4) Identifying devices properly >> >> In contrast to the previous point, stateful apps might have a problem >> identifying devices after hotplug. For example, let's say you don't >> care about the addresses and leave that up to libvirt. You hotplug a >> device into the domain and dump the new XML of it. Depending on what >> type of device it was, you might need to identify it based on different >> values. It could be <target dev=3D''/> for disks, <mac address=3D''/> f= or >> interfaces etc. For some devices it might not even be possible and you >> need to remember the addresses of all the previous devices and then >> parse them just to identify that one device and then throw them away. >> >> With new enough libvirt you could use the user aliases for that, but >> turns out it's not that easy to use them properly anyway. Also the >> aliases won't help users identify that device inside the guest. > >NB, relating between host device config and guest visible device >config is a massive problem space in its own right, and not very >easy to address. In OpenStack we ended up defining a concept of >"device tagging" via cloud-init metadata, where openstack allows >users to set opaque string tags against devices their VM has. >OpenStack that generates a metadata file that records various >pieces of identifying hardware attributes (PCI address, MAC >addr, disk serial, etc) alongside the user tag. This metadata >file is exposed to the guest with the hope that there's enough >info to allow the user to decide which device is to be used for >which purpose > This is good point, but I was mostly thinking about identifying devices =66rom the host POV between two different XMLs (pre- and post- some XML-modifying action, like hotplug). >https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/vir= t-device-role-tagging.html >https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/1= 0/html/networking_guide/use-tagging > >> <rant> >> We really should've gone with new attribute for the user alias instead >> of using an existing one, given how many problems that is causing. >> </rant> >> >> 5) Generating the right XML snippet for device hot-(un)plug >> >> This is kind of related to some previous points. >> >> When hot-plugging a device and creating an XML snippet for it, you want >> to keep the defaults from point 1) and policies from 2) in mind. Or >> something related to the already existing domain which you can describe >> systematically. And adding something for identification (see previous >> point). >> >> Doing the hot-unplug is easy depending on how much information about >> that device is saved by your application. The less you save about the >> device (or show to the user in a GUI, if applicable) the harder it might >> be to generate an XML that libvirt will accept. Again, some problems >> with this should be fixed in libvirt, some of them are easy to >> workaround. But having a common ground that takes care of this should >> help some projects. >> >> Hot-unplug could be implemented just based on the alias. This is >> something that would fit into libvirt as well. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> To mention some pre-existing solutions: >> >> - I understand OpenStack has some really sensible and wisely chosen >> and/or tested default values. > >In terms of default devices and OS specific choices, OpenStack's >decisions have been largely inspired by previous work in oVirt >and / or virt-manager. So there's obviously overlap in the >conceptual area, but there's also plenty that is very specific >to OpenStack - untangling the two extract the common bits from >the app specific bits is hard. > It definitely is, but do you think it's so difficult it's worthless to pursuit? I did a tiny PoC based on the code from virt-manager, which was trivial mainly thanks to the XMLBuilder for the domain objects. Maybe exposing an easy way to work with the XML would be enough for some projects. Little birdie from oVirt told me that they would like some of sort of thing that does what you can achieve with virt-xml if we, for example, made it work on pure XML definitions without connecting to libvirt. >> - I know KubeVirt has VirtualMachinePresets. That is something closely >> related to points 1) and 2). Also their abstraction of the XML might >> be usable for point 3). >> >> - There was an effort on creating policy based configuration of libvirt >> objects called libvirt-designer. This is closely related to points 2) >> and 3). Unfortunately there was no much going on lately and part of >> virt-manager repository has currently more features implemented with >> the same ideas in mind, just not exported for public use. > >This is the same kind of problem we faced wrt libvirt-gconfig and >libvirt-gobject usage from virt-manager - it has an extensive code >base that already works, and rewriting it to use something new >is alot of work for no short-term benefit. libvirt-gconfig/gobject >were supposed to be the "easy" bits for virt-manager to adopt, as >they don't really include much logic that would step on virt-manager's >toes. libvirt-designer was going to be a very opinionated library >and in retrospective that makes it even harder to consider adopting >it for usage in virt-manager, as it'll have signficant liklihood >of making functionally significant changes in behaviour. > The initial idea (which I forgot to mention) was that all the decisions libvirt currently does (so that it keeps the guest ABI stable) would be moved into data (let's say some DSL) and it could then be switched or adjusted if that's not what the mgmt app wants (on a per-definition basis, of course). I didn't feel very optimistic about the upstream acceptance for that idea, so I figured that there could be something that lives beside libvirt, helps with some policies if requested and then the resulting XML could be fed into libvirt for determining the rest. >There's also the problem with use of native libraries that would >impact many apps. We only got OpenStack to grudgingly allow the By native you mean actual binary libraries or native to the OpenStack code as in python module? Because what I had in mind for this project was a python module with optional wrapper for REST API. >use of libosinfo native library via GObject Introspection, by >promising to do work to turn the osinfo database into an approved >stable format which OpenStack could then consume directly, dropping >the native API usage :-( Incidentally, the former was done (formal >spec for the DB format), but the latter was not yet (direct DB usage >by OpenStack) > > >BTW, I don't like that I'm being so negative to your proposal :-( >I used to hope that we would be able to build higher level APIs on >top of libvirt to reduce the overlap between different applications >reinventing the wheel. Even the simplest bits we tried like the >gconfig/gobject API are barely used. libvirt-designer is basically >a failure. Though admittedly it didn't have enough development resource >applied to make it compelling, in retrospect adoption was always going >to be a hard sell except in greenfield developments. > I'm glad for the knowledge you provided. So maybe instead of focusing on de-duplication of existing codebases we could _at least_ aim at future mgmt apps. OTOH improving documentation on how to properly build higher level concepts on top of libvirt would benefit them as well. >Libosinfo is probably the bit we've had most success with, and has >most promise for the future, particularly now that we formally allow >apps to read the osinfo database directly and bypass the API. It is >quite easy to fit into existing application codebases which helps alot. >Even there I'm still disappointed that we only have GNOME Boxes using >the kickstart generator part of osinfo - oVirt and Oz both still have >their own kickstart generator code for automating OS installs. > >In general though, I fear anything API based is going to be a really >hard sell to get wide adoption for based on what we've seen before. > >I think the biggest bang-for-buck is identifying more areas where we >can turn code into data. There's definitely scope for recording more >types of information in the osinfo database. There might also be >scope for defining entirely new databases to complement the osinfo >data, if something looks out of scope for libosinfo. > >Regards, >Daniel >--=20 >|: https://berrange.com -o- https://www.flickr.com/photos/dberrang= e :| >|: https://libvirt.org -o- https://fstop138.berrange.co= m :| >|: https://entangle-photo.org -o- https://www.instagram.com/dberrang= e :| --ieNMXl1Fr3cevapt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEiXAnXDYdKAaCyvS1CB/CnyQXht0FAlqzw4kACgkQCB/CnyQX ht0G+xAAnvv+RKtfL7aDX7nVWclilDw7XYt+0a01KuLoF7a9FZ0emZgRr2tiX8NO iTU1t68Ch62vni+FY77cuPM7eixUdYEwUaVybptJvWKzAgladXpA93ZfsT0wGxpi qIrkpgbJmiAULogBrc8ia2bqy2MpFDIFAPzsMDTsznJH/cJMErA+Hg5A8VVOt0Cl j6uwGCT7MYRBK2/th3Q0POVLtnj6MnXbuTda3sl45aNMnOEDmxKNW+zNdgUfbAxO 0GdjfypwJyFIz4FZRrVvlnMEHlqkZyJcDF6BQN+lVKsTizcDAYV6QM3snNLTFgsF huIcrMsWNnDG/GsbkFyc6XkvPeZ6xonMW0LEYHP6pLTyg1CGIJ7E6VaPNlEVRU+J aJjqHEW14oTc6ttuf8m7El972ATXgY6l1W4FiQisIy7PpwpGb896zoaEyYryGJT4 WWXFW60QoDPNmjHgA4S0PdefEuKrD1u5BUYVExpVW7ud8uyggssKz6id7mv+4J6Y Jv0WaaIA/l53mInyEzOpTHT6tMExH64tHF2RdghQ+r7tzNxtCmBDmj3QcwHzaa97 +R0txkevMqJ57l2QvWKc2z7CJHsuZqolDrGpMUJ35PFOqAeq2elj9F4fmUlV+nt5 Ju4qL3mrJ4AdhtXBACcQLNqUsbgGs1E99gY2v9mpJOPvSyVD5O0= =L9yQ -----END PGP SIGNATURE----- --ieNMXl1Fr3cevapt--

3 4

oVirt log analyzer
by Milan Zamazal 04 Apr '18

04 Apr '18

Hi, during last year Outreachy internship a tool for analyzing oVirt logs was created. When it is provided with oVirt logs (such as SOS reports, logs gathered by Lago, single or multiple log files) it tries to identify and classify important lines from the logs and present them in a structured form. Its primary purpose is to get a quick and easy overview of actions and errors. The tool analyses given logs and produces text files with the extracted information. There is an Emacs user interface that presents the output in a nice way with added functionality such as filtering. Emacs haters can use the plain text files or write another user interface. :-) You can get ovirt-log-analyzer from https://github.com/mz-pdm/ovirt-log-analyzer README.md explains how to use it. Note that ovirt-log-analyzer has been created within the limited resources of an Outreachy internship with some additional work and not everything is perfect. Feel free to make improvements. Regards, Milan

6 10

Failed To Build ovirt-node following the guide
by sundw 02 Apr '18

02 Apr '18

This is a multi-part message in MIME format. ------=_001_NextPart058565458615_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8sZ3V5c6OhDQoNCkkgYnVpbHQgb3ZpcnQtbm9kZSBmb2xsb3dpbmcgdGhpcyBndWlkZSho dHRwczovL3d3dy5vdmlydC5vcmcvZGV2ZWxvcC9wcm9qZWN0cy9ub2RlL2J1aWxkaW5nLykuDQpC dXQgSSBmYWlsZWQuDQpJIGdvdCB0aGUgZm9sbG93aW5nIEVycm9yIG1lc3NhZ2UgYWZ0ZXIgcnVu bmluZyAibWFrZSBpc28gcHVibGlzaCI6DQoNCkVycm9yIGNyZWF0aW5nIExpdmUgQ0QgOiBGYWls ZWQgdG8gZmluZCBwYWNrYWdlICdvdmlydC1ub2RlLXBsdWdpbi12ZHNtJyA6IE5vIHBhY2thZ2Uo cykgYXZhaWxhYmxlIHRvIGluc3RhbGwNCg0KQ291bGQgeW91IHBsZWFzZSBnaXZlIHNvbWUgYWR2 aWNlPw0KDQpCVFc6IElzIHRoZSBjb250ZW50IG9mIHRoaXMgdXJsICJodHRwczovL3d3dy5vdmly dC5vcmcvZGV2ZWxvcC9wcm9qZWN0cy9ub2RlL2J1aWxkaW5nLyIgT1VUIE9GIERBVEU/DQoNCg0K DQrL77TzzqENCrGxvqm/xtL4vqmzyby8yvXT0M/euavLvi/QwrL6xrfR0Leisr8NCjEzMzc4MTA1 NjI1DQo= ------=_001_NextPart058565458615_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DGB2312"><style>body { line-height: 1.5; }body { font-size: 10.5pt; fon= t-family: =CE=A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5;= }</style></head><body>=0A<div><span></span><span style=3D"color: rgb(0, 0= , 0); background-color: rgba(0, 0, 0, 0);">Hello,guys=A3=A1</span></div><d= iv><span style=3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);= "><br>I built ovirt-node following this guide(htt= ps://www.ovirt.org/develop/projects/node/building/)<br>But I fa= iled.<br>I got the following Error message after = running "make iso publish":<br><br>Error creating&nbsp= ;Live CD : Failed to find package 'ovir= t-node-plugin-vdsm' : No package(s) available to&= nbsp;install<br><br>Could you please give some ad= vice?</span></div><div><span style=3D"color: rgb(0, 0, 0); background-colo= r: rgba(0, 0, 0, 0);"><br></span></div><div><b><span style=3D"color: rgb(0= , 0, 0); background-color: rgba(0, 0, 0, 0);">BTW: Is the content of this = url "</span><span style=3D"font-size: 10.5pt; line-height: 1.5; background= -color: window;">https://www.ovirt.org/develop/projects/node/building/</sp= an><span style=3D"background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; l= ine-height: 1.5;">" OUT OF DATE?</span></b></div><div><br></div><hr style= =3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align=3D"left= ">=0A<div><span><div style=3D"margin: 10px; font-size: 21px;"><b><font fac= e=3D"=BB=AA=CE=C4=D0=C2=CE=BA">=CB=EF=B4=F3=CE=A1</font></b></div><div sty= le=3D"MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt">=B1=B1=BE=A9=BF= =C6=D2=F8=BE=A9=B3=C9=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE/=D0=C2=B2=FA=C6= =B7=D1=D0=B7=A2=B2=BF</div><div style=3D"MARGIN: 10px; FONT-FAMILY: verdan= a; FONT-SIZE: 10pt">13378105625</div></span></div>=0A</body></html> ------=_001_NextPart058565458615_=------

3 2

Build virt-node on fedora26 failed
by sundw 02 Apr '18

02 Apr '18

This is a multi-part message in MIME format. ------=_001_NextPart018013562620_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkhDQpJIGJ1aWxkIHZpcnQtbm9kZSBiYXNlIG9uIHRoaXMgZ3VpZGUoaHR0cHM6Ly93d3cub3Zp cnQub3JnL2RldmVsb3AvcHJvamVjdHMvbm9kZS9idWlsZGluZy8pLg0KSSBnb3QgdGhlIGZvbGxv d2luZyBlcnJvciBtZXNzYWdlcyBhZnRlciBJIHJ1biAibWFrZSBwdWJsaXNoIjoNCg0KSW5zdGFs bGluZyB0bXAucmVwb3MvU1JQTVMvb3ZpcnQtbm9kZS0zLjcuMC0wLjAubWFzdGVyLmZjMjcuc3Jj LnJwbQ0KZXJyb3I6IEZhaWxlZCBidWlsZCBkZXBlbmRlbmNpZXM6DQovdXNyL3NoYXJlL3NlbGlu dXgvZGV2ZWwvcG9saWN5aGVscCBpcyBuZWVkZWQgYnkgb3ZpcnQtbm9kZS0zLjcuMC0wLjAubWFz dGVyLmZjMjcubm9hcmNoDQptYWtlWzFdOiAqKiogW01ha2VmaWxlOjgxMzogcnBtXSBFcnJvciAx DQptYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSAnL2hvbWUvY29yZXRlay9naXQvb3ZpcnQtbm9k ZScNCm1ha2U6ICoqKiBbTWFrZWZpbGU6ODI3OiBwdWJsaXNoXSBFcnJvciAyDQoNCkNhbiBhbnlv bmUgZ2l2ZSBtZSBzb21lIHN1Z2dlc3Rpb25zPyANClRoYW5rcyENCg0KDQoNCg0Ky++0886hDQqx sb6pv8bS+L6ps8m8vMr109DP3rmry74v0MKy+sa30dC3orK/DQoxMzM3ODEwNTYyNQ0K ------=_001_NextPart018013562620_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DGB2312"><style>body { line-height: 1.5; }body { font-size: 10.5pt; fon= t-family: =CE=A2=C8=ED=D1=C5=BA=DA; color: rgb(0, 0, 0); line-height: 1.5;= }</style></head><body>=0A<div><span></span>Hi!</div><div>I build virt-nod= e base on this guide(<span style=3D"background-color: rgba(0, 0, 0, 0); fo= nt-size: 10.5pt; line-height: 1.5;">https://www.ovirt.org/develop/projects= /node/building/</span><span style=3D"font-size: 10.5pt; line-height: 1.5; = background-color: window;">).</span></div><div>I got the following error m= essages after I run "make publish":</div><div><br></div><div><span style= =3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">Installing&n= bsp;tmp.repos/SRPMS/ovirt-node-3.7.0-0.0.master.fc27.src.rpm<br>error:&nbs= p;Failed build dependencies:<br><span style=3D"white-space: pre;= "> </span>/usr/share/selinux/devel/policyhelp is needed by&= nbsp;ovirt-node-3.7.0-0.0.master.fc27.noarch<br>make[1]: *** [Ma= kefile:813: rpm] Error 1<br>make[1]: Leaving dire= ctory '/home/coretek/git/ovirt-node'<br>make: *** [Makefile= :827: publish] Error 2</span></div><div><span style=3D"colo= r: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span></div><di= v><span style=3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"= >Can anyone give me some suggestions? </span></div><div><span style= =3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">Thanks!</spa= n></div><div><br></div>=0A<div><br></div><hr style=3D"width: 210px; height= : 1px;" color=3D"#b5c4df" size=3D"1" align=3D"left">=0A<div><span><div sty= le=3D"margin: 10px; font-size: 21px;"><b><font face=3D"=BB=AA=CE=C4=D0=C2= =CE=BA">=CB=EF=B4=F3=CE=A1</font></b></div><div style=3D"MARGIN: 10px; FON= T-FAMILY: verdana; FONT-SIZE: 10pt">=B1=B1=BE=A9=BF=C6=D2=F8=BE=A9=B3=C9= =BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE/=D0=C2=B2=FA=C6=B7=D1=D0=B7=A2=B2=BF<= /div><div style=3D"MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt">13= 378105625</div></span></div>=0A</body></html> ------=_001_NextPart018013562620_=------

2 1

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 27-03-2018 ] [ 004_basic_sanity.disk_operations ]
by Dafna Ron 02 Apr '18

02 Apr '18

Hi, We have a failure on 004_basic_sanity.disk_operations. the reported change seems to me to be connected to the failure. *Link and headline of suspected patches: core: introduce CreateSnapshotForVm - https://gerrit.ovirt.org/#/c/87671/ <https://gerrit.ovirt.org/#/c/87671/>Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/artifact…>(Relevant) error snippet from the log: <error>2018-03-27 11:30:16,167-04 WARN [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default task-11) [9f713a3d-82a9-4db8-8207-bb69a0a2c550] Validation of action 'CreateSnapshotForVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__CREATE,VAR__TYPE__SNAPSHOT,ACTION_TYPE_FAILED_SNAPSHOT_IS_BEING_TAKEN_FOR_VM,$VmName vm12018-03-27 11:30:16,176-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-11) [9f713a3d-82a9-4db8-8207-bb69a0a2c550] method: runAction, params: [CreateSnapshotForVm, CreateSnapshotForVmParameters:{commandId='d8bfdb0e-5ae4-4fed-8852-a0b29e377708', user='null', commandType='Unknown', vmId='65e7fea5-8b7d-4281-bd0d-6a84de207a00'}], timeElapsed: 57ms2018-03-27 11:30:16,186-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-11) [] Operation Failed: [Cannot create Snapshot. Snapshot is currently being created for VM vm1.]2018-03-27 11:30:16,820-04 INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-100) [16c08ce6-9a73-489f-a1f2-56e21699f14a] Command 'CopyImageGroupVolumesData' (id: '4c4023b4-21e8-4a98-8ac3-aba51967d160') waiting on child command id: '3d96b933-6e3b-4838-94bc-db3ff0cadcdc' type:'CopyData' to complete2018-03-27 11:30:16,833-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (EE-ManagedThreadFactory-engineScheduled-Thread-100) [16c08ce6-9a73-489f-a1f2-56e21699f14a] method: get, params: [a85992e9-40b8-4c80-9c93-3bf767f6efa4], timeElapsed: 8ms</error>*

4 9

[VDSM] Network test failing randomly - needs un-ordered compare?
by Nir Soffer 30 Mar '18

30 Mar '18

We have this failure in unrelated patch: http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22723/conso… The issue seems to comparing strings instead of sets. The next run was successful. I did not check if it run on the same slave. http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22724/ *00:08:51.242* =================================== FAILURES =================================== *00:08:51.243* ________________ LinkBondTests.test_bond_set_two_arp_ip_targets ________________*00:08:51.243* *00:08:51.243* self = <network.integration.link_bond_test.LinkBondTests testMethod=test_bond_set_two_arp_ip_targets>*00:08:51.244* *00:08:51.244* def test_bond_set_two_arp_ip_targets(self):*00:08:51.244* OPTIONS = {*00:08:51.244* 'mode': '1',*00:08:51.245* 'arp_interval': '1000',*00:08:51.245* 'arp_ip_target': '10.1.3.1,10.1.2.1'}*00:08:51.245* *00:08:51.245* with bond_device() as bond:*00:08:51.245* bond.set_options(OPTIONS)*00:08:51.246* bond.refresh()*00:08:51.246* > self.assertEqual(bond.options, OPTIONS)*00:08:51.246* E AssertionError: {'mode': '1', 'arp_interval': '1000', 'arp_ip_target': '10.1.2.1,10.1.3.1'} != {'mode': '1', 'arp_interval': '1000', 'arp_ip_target': '10.1.3.1,10.1.2.1'}*00:08:51.248* E - {'arp_interval': '1000', 'arp_ip_target': '10.1.2.1,10.1.3.1', 'mode': '1'}*00:08:51.248* E ? ---------*00:08:51.249* E *00:08:51.249* E + {'arp_interval': '1000', 'arp_ip_target': '10.1.3.1,10.1.2.1', 'mode': '1'}*00:08:51.249* E ? +++++++++*00:08:51.250* *00:08:51.250* network/integration/link_bond_test.py:159: AssertionError*00:08:51.250* ------------------------------ Captured log call -------------------------------*00:08:51.251* sysfs_driver.py 57 INFO Bond bond_ge9DfJ has been created.*00:08:51.251* cmdutils.py 150 DEBUG /sbin/ip link set dev bond_ge9DfJ down (cwd None)*00:08:51.252* cmdutils.py 158 DEBUG SUCCESS: <err> = ''; <rc> = 0*00:08:51.252* sysfs_driver.py 102 INFO Bond bond_ge9DfJ options set: {'mode': '1', 'arp_interval': '1000', 'arp_ip_target': '10.1.3.1,10.1.2.1'}.*00:08:51.253* sysfs_driver.py 67 INFO Bond bond_ge9DfJ has been destroyed.*00:08:51.254* =============== 1 failed, 36 passed, 12 skipped in 10.57 seconds ===============

1 0

new time-based test randomly failing
by Dan Kenigsberg 29 Mar '18

29 Mar '18

I suppose this test should be reworked, or at least, have its constants tweaked. FAIL: test_slow_handler_sync (common.logutils_test.TestThreadedHandler) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/tests/common/logutils_test.py", line 319, in test_slow_handler_sync self.assertGreater(max(workers_time), 0.9) AssertionError: 0.8714249134063721 not greater than 0.9

2 5

OST Failure - Weekly update [24/03/2018-29/03/2018]
by Dafna Ron 29 Mar '18

29 Mar '18

Hello, I would like to update on this week's failures and OST current status. This week I am sending the report a bit earlier due to the holidays. We had a few failures this week but I am glad to report that the issues were fixed quickly. on 23-03-2018 we started getting a random failure which seems to be an issue with the ost test hotplug_cpu This fix was submitted by Milan to fix the issue: https://gerrit.ovirt.org/89589 On the 27-03-2018 we had a failure on basic_sanity.disk_operations This seems to be related to locking race and was fixed by Benny on 3 different fixes: https://gerrit.ovirt.org/#/c/89534/ https://gerrit.ovirt.org/#/c/89537/ https://gerrit.ovirt.org/#/c/89577/ There was an issue with build-artifacts on the vdsm project which was an infra failure as well as a code issue (2 different builds). this was also resolved quickly. Infra issues: The ci team discovered and fixed a failure in container cleanup on the the hosts. Daniel submitted this patch: https://gerrit.ovirt.org/#/c/89402/ and it seemed to have resolved the issue. Gal has been investigating an issue which causes failure due to lack of memory on the host. for now, Gal submitted a fix: https://gerrit.ovirt.org/#/c/89588/ Lastly we had a packaging issue on 4.2 which was resolved as well. *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 of resolved failures based on ovirt version* *Below is a chart showing failures by suite type: * *Thanks, * *Dafna*

1 0

[vdsm] network/integration test failures
by Francesco Romani 29 Mar '18

29 Mar '18

This is a multi-part message in MIME format. --------------3945872423EDD8DBF79FFA16 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi developers, we had another network CI failure while testing unrelated changes: http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22708/conso… *12:20:19* self = <network.integration.link_bond_test.LinkBondTests testMethod=test_bond_clear_arp_ip_target> *12:20:19* *12:20:19* def test_bond_clear_arp_ip_target(self): *12:20:19* OPTIONS_A = { *12:20:19* 'mode': '1', *12:20:19* 'arp_interval': '1000', *12:20:19* 'arp_ip_target': '192.168.122.1'} *12:20:19* OPTIONS_B = { *12:20:19* 'mode': '1', *12:20:19* 'arp_interval': '1000'} *12:20:19* *12:20:19* with bond_device() as bond: *12:20:19* > bond.set_options(OPTIONS_A) *12:20:19* *12:20:19* network/integration/link_bond_test.py:171: Could please some network developer have a look? Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh --------------3945872423EDD8DBF79FFA16 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>Hi developers,</p> <p><br> </p> <p>we had another network CI failure while testing unrelated changes:</p> <p><br> </p> <p><a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22708/conso…">http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22708/conso…</a></p> <p><br> </p> <pre class="console-output"><span class="timestamp"><b>12:20:19</b> </span>self = <network.integration.link_bond_test.LinkBondTests testMethod=test_bond_clear_arp_ip_target> <span class="timestamp"><b>12:20:19</b> </span> <span class="timestamp"><b>12:20:19</b> </span> def test_bond_clear_arp_ip_target(self): <span class="timestamp"><b>12:20:19</b> </span> OPTIONS_A = { <span class="timestamp"><b>12:20:19</b> </span> 'mode': '1', <span class="timestamp"><b>12:20:19</b> </span> 'arp_interval': '1000', <span class="timestamp"><b>12:20:19</b> </span> 'arp_ip_target': '192.168.122.1'} <span class="timestamp"><b>12:20:19</b> </span> OPTIONS_B = { <span class="timestamp"><b>12:20:19</b> </span> 'mode': '1', <span class="timestamp"><b>12:20:19</b> </span> 'arp_interval': '1000'} <span class="timestamp"><b>12:20:19</b> </span> <span class="timestamp"><b>12:20:19</b> </span> with bond_device() as bond: <span class="timestamp"><b>12:20:19</b> </span>> bond.set_options(OPTIONS_A) <span class="timestamp"><b>12:20:19</b> </span> <span class="timestamp"><b>12:20:19</b> </span>network/integration/link_bond_test.py:171: Could please some network developer have a look? Bests, </pre> <pre class="moz-signature" cols="72">-- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh</pre> </body> </html> --------------3945872423EDD8DBF79FFA16--

2 1

[ OST Failure Report ] [ oVirt Master (log-collector/engine/vdsm) ] [ 23/25/26-03-2018 ] [004_basic_sanity.hotplug_cpu ]
by Dafna Ron 29 Mar '18

29 Mar '18

Hi, We have a failure that seems to be random and happening in several projects. from what I can see, we are failing due to a timing issue in the test itself because we are querying the vm after its been destroyed in engine. looking at engine, I can see that the vm was actually shut down, I would like to disable this test until we can fix the issue since it already failed about 7 different patches from different projects. *Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6521/artifact…>(Relevant) error snippet from the log: <error>* *engine: 018-03-23 14:44:14,156-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-5) [] Failed to destroy VM '7020944f-cd26-4c31-b381-0ce6be733fd7' because VM does not exist, ignoring2018-03-23 14:44:14,156-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-5) [] FINISH, DestroyVDSCommand, log id: 646766a2018-03-23 14:44:14,156-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (ForkJoinPool-1-worker-5) [] method: runVdsCommand, params: [Destroy, DestroyVmVDSCommandParameters:{hostId='c40b11df-7053-437e-8acc-c5e91c1694bc', vmId='7020944f-cd26-4c31-b381-0ce6be733fd7', secondsToWait='0', gracefully='false', reason='', ignoreNoVm='true'}], timeElapsed: 14ms2018-03-23 14:44:14,156-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (ForkJoinPool-1-worker-5) [] method: getVmManager, params: [7020944f-cd26-4c31-b381-0ce6be733fd7], timeElapsed: 0ms2018-03-23 14:44:14,156-04 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-5) [] VM '7020944f-cd26-4c31-b381-0ce6be733fd7'(vm2) moved from 'Up' --> 'Down'2018-03-23 14:44:14,156-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (ForkJoinPool-1-worker-5) [] method: getVmManager, params: [7020944f-cd26-4c31-b381-0ce6be733fd7], timeElapsed: 0ms2018-03-23 14:44:14,177-04 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-4) [a463501f-f01a-4048-93ca-02647308394b] EVENT_ID: USER_STOP_VM(33), VM vm2 powered off by admin@internal-authz (Host: lago-basic-suite-master-host-0).* *vdsm: 2018-03-23 14:44:14,024-0400 INFO (libvirt/events) [virt.vm] (vmId='7020944f-cd26-4c31-b381-0ce6be733fd7') Changed state to Down: Admin shut down from the engine (code=6) (vm:1684)2018-03-23 14:44:14,028-0400 INFO (jsonrpc/1) [api.virt] FINISH destroy return={'status': {'message': 'Machine destroyed', 'code': 0}} from=::ffff:192.168.201.4,53454, flow_id=a463501f-f01a-4048-93ca-02647308394b, vmId=7020944f-cd26-4c31-b381-0ce6be733fd7 (api:52)2018-03-23 14:44:14,028-0400 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call VM.destroy succeeded in 1.72 seconds (__init__:311)2018-03-23 14:44:14,031-0400 INFO (periodic/2) [Executor] Worker was discarded (executor:305)2018-03-23 14:44:14,033-0400 INFO (libvirt/events) [virt.vm] (vmId='7020944f-cd26-4c31-b381-0ce6be733fd7') Stopping connection (guestagent:440)2018-03-23 14:44:14,033-0400 ERROR (libvirt/events) [vds] Error running VM callback (clientIF:666)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 629, in dispatchLibvirtEvents v.onLibvirtLifecycleEvent(event, detail, None)AttributeError: 'NoneType' object has no attribute 'onLibvirtLifecycleEvent'2018-03-23 14:44:14,078-0400 INFO (jsonrpc/4) [api.virt] START destroy(gracefulAttempts=1) from=::ffff:192.168.201.4,53454, vmId=7020944f-cd26-4c31-b381-0ce6be733fd7 (api:46)2018-03-23 14:44:14,078-0400 INFO (jsonrpc/4) [api] FINISH destroy error=Virtual machine does not exist: {'vmId': u'7020944f-cd26-4c31-b381-0ce6be733fd7'} (api:127)2018-03-23 14:44:14,079-0400 INFO (jsonrpc/4) [api.virt] FINISH destroy return={'status': {'message': "Virtual machine does not exist: {'vmId': u'7020944f-cd26-4c31-b381-0ce6be733fd7'}", 'code': 1}} from=::ffff:192.168.201.4,53454, vmId=7020944f-cd26-4c31-b381-0ce6be733fd7 (api:52)* *</error>*

2 5

[ENGINE] JUnit version upgrade
by Allon Mureinik 28 Mar '18

28 Mar '18

Hi oVirt Engine developers, I've just merged a patch to bump oVirt Engine's JUnit requirement to the latest available 5.1 GA. As a first step, I've integrated the vintage engine, which is a drop-in replacement that can run old JUnit 4 (and even JUnit 3!) tests, just with a newer runtime engine. This isn't the final goal, but a first step towards moving to the newer Jupiter engine, which won't be a clean dependency replacement. Please let me know if you encounter any problem. Regards, Allon

1 0

OST Failure - Weekly update [17/03/2018-23/03/2018]
by Dafna Ron 26 Mar '18

26 Mar '18

Hello, I would like to update on this week's failures and OST current status. On 19-03-2018 - the CI team reported 3 different failures. On Master branch the failed changes reported were: *core: fix removal of vm-host device - https://gerrit.ovirt.org/#/c/89145/ <https://gerrit.ovirt.org/#/c/89145/>* *core: USB in osinfo configuration depends on chipset - https://gerrit.ovirt.org/#/c/88777/ <https://gerrit.ovirt.org/#/c/88777/>* *On 4.2 *branch, the reported change was: *core: Call endAction() of all child commands in ImportVmCommand - https://gerrit.ovirt.org/#/c/89165/ <https://gerrit.ovirt.org/#/c/89165/>* The fix's for the regressions were merged the following day (20-03-2018) https://gerrit.ovirt.org/#/c/89250/- core: Replace generic unlockVm() logic in ImportVmCommand https://gerrit.ovirt.org/#/c/89187/ - core: Fix NPE when creating an instance type On 20-03-2018 - the CI team discovered an issue on the job's cleanup which caused random failures on changes testing due to failure in docker cleanup. There is an open Jira on the issue: https://ovirt-jira.atlassian.net/browse/OVIRT-1939 *Below you can see the chart for this week's resolved issues but cause of failure:*Code = regression of working components/functionalities Configurations = package related issues Other = failed build artifacts Infra = infrastructure/OST/Lago related issues *Below is a chart of resolved failures based on ovirt version* *Below is a chart showing failures by suite type: * Thank you, Dafna

6 12

[ OST Failure Report ] [ oVirt Master (ovirt-engine-nodejs-modules) ] [ 23-03-2018] [ 002_bootstrap.check_update_host ]
by Dafna Ron 24 Mar '18

24 Mar '18

Hi, we had a failure reported in CQ for change: https://gerrit.ovirt.org/#/c/89338/ - Bump 1.5.2-1. I don't think the failure is related to the change. it seems to be an issue with mom failing to start. *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/89338/ <https://gerrit.ovirt.org/#/c/89338/> - Bump 1.5.2-1Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6512/artifact…>(Relevant) error snippet from the log: <error>* *engine: *018-03-23 07:12:33,435-04 ERROR [org.ovirt.engine.core.bll.host.HostUpgradeManager] (EE-ManagedThreadFactory-commandCoordinator-Thread-1) [7a4f81e6-6ae6-4444-ace6-de757e78f41e] Failed to run check-update of host 'lago-basic-suite-master- host-0'. 2018-03-23 07:12:33,436-04 ERROR [org.ovirt.engine.core.bll.hostdeploy.HostUpdatesChecker] (EE-ManagedThreadFactory-commandCoordinator-Thread-1) [7a4f81e6-6ae6-4444-ace6-de757e78f41e] Failed to check if updates are available for host 'lag o-basic-suite-master-host-0' with error message 'Failed to run check-update of host 'lago-basic-suite-master-host-0'.' 2018-03-23 07:12:33,441-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-commandCoordinator-Thread-1) [7a4f81e6-6ae6-4444-ace6-de757e78f41e] EVENT_ID: HOST_AVAILABLE_UPDATES_FAILED(8 39), Failed to check for available updates on host lago-basic-suite-master-host-0 with message 'Failed to run check-update of host 'lago-basic-suite-master-host-0'.'. 2018-03-23 07:12:33,566-04 DEBUG [org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-11) [] START, GetAllVmStatsVDSCommand(HostName = lago-basic-suite-master-host-0, VdsIdVDS CommandParametersBase:{hostId='dc339bcf-b769-41f6-8252-c61fffd56b17'}), log id: 4eb92a5a 2018-03-23 07:12:33,567-04 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (EE-ManagedThreadFactory-engineScheduled-Thread-11) [] SEND destination:jms.topic.vdsm_requests reply-to:jms.topic.vdsm_responses content-length:103 *host-0:* vdsm log show: momStatus': 'inactive' *Mom log: * 2018-03-23 07:09:48,849 - mom - INFO - MOM starting 2018-03-23 07:09:48,864 - mom.HostMonitor - INFO - Host Monitor starting 2018-03-23 07:09:48,867 - mom - INFO - hypervisor interface vdsmjsonrpcclient 2018-03-23 07:09:48,983 - mom - ERROR - Failed to initialize MOM threads Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run hypervisor_iface = self.get_hypervisor_interface() File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, in get_hypervisor_interface return module.instance(self.config) File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcclientInterface.py", line 96, in instance return JsonRpcVdsmClientInterface() File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcclientInterface.py", line 31, in __init__ self._vdsm_api = client.connect(host="localhost") File "/usr/lib/python2.7/site-packages/vdsm/client.py", line 139, in connect raise ConnectionError(host, port, use_tls, timeout, e) ConnectionError: Connection to localhost:54321 with use_tls=True, timeout=60 failed: [Errno 111] Connection refused 2018-03-23 07:09:54,475 - mom - INFO - MOM starting 2018-03-23 07:09:54,499 - mom.HostMonitor - INFO - Host Monitor starting 2018-03-23 07:09:54,500 - mom - INFO - hypervisor interface vdsmjsonrpcclient 2018-03-23 07:09:54,725 - mom.HostMonitor - INFO - HostMonitor is ready 2018-03-23 07:09:54,813 - mom.GuestManager - INFO - Guest Manager starting: multi-thread 2018-03-23 07:09:54,819 - mom.Policy - INFO - Loaded policy '00-defines' 2018-03-23 07:09:54,820 - mom.Policy - INFO - Loaded policy '01-parameters' 2018-03-23 07:09:54,841 - mom.Policy - INFO - Loaded policy '02-balloon' 2018-03-23 07:09:54,871 - mom.Policy - INFO - Loaded policy '03-ksm' 2018-03-23 07:09:54,909 - mom.Policy - INFO - Loaded policy '04-cputune' 2018-03-23 07:09:54,951 - mom.Policy - INFO - Loaded policy '05-iotune' 2018-03-23 07:09:54,956 - mom.PolicyEngine - INFO - Policy Engine starting 2018-03-23 07:09:54,957 - mom.RPCServer - INFO - Using unix socket /var/run/vdsm/mom-vdsm.sock 2018-03-23 07:09:54,957 - mom.RPCServer - INFO - RPC Server starting 2018-03-23 07:10:10,020 - mom.Controllers.KSM - INFO - Updating KSM configuration: pages_to_scan:0 merge_across_nodes:1 run:0 sleep_millisecs:0 lago-basic-suite-master-host-0/_var_log/vdsm/mom.log (END) *</error>*

2 1

oVirt on the main page of redhatofficial.github.io
by Nir Soffer 23 Mar '18

23 Mar '18

https://redhatofficial.github.io/#!/main [image: Screenshot from 2018-03-23 18-01-07.png] Thanks for the great work Brian! Nir

1 0

Fwd: Project for profiles and defaults for libvirt domains
by Michal Skrivanek 22 Mar '18

22 Mar '18

--Apple-Mail=_6D569541-1CA3-4944-AFE7-86FD31122B7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii cross-posting to the right list, by mistake a wrong ovirt list was used = originally > Begin forwarded message: >=20 > From: Martin Kletzander <mkletzan(a)redhat.com> > Subject: [kubevirt-dev] Project for profiles and defaults for libvirt = domains > Date: 20 March 2018 at 15:20:31 CET > To: libvir-list(a)redhat.com, openstack-dev(a)lists.openstack.org, = ovirt-devel(a)redhat.com, kubevirt-dev(a)googlegroups.com, = virt-tools-list(a)redhat.com, cockpit-devel(a)lists.fedorahosted.org >=20 > Hi everyone! >=20 > First of all sorry for such wide distribution, but apparently that's = the > best way to make sure we cooperate nicely. So please be considerate = as > this is a cross-post between huge amount of mailing lists. >=20 > After some discussions with developers from different projects that = work > with libvirt one cannot but notice some common patterns and = workarounds. > So I set off to see how can we make all our lives better and our = coding > more effective (and maybe more fun as well). If all goes well we will > create a project that will accommodate most of the defaulting, = policies, > workarounds and other common algorithms around libvirt domain > definitions. And since early design gets you half way, I would like = to > know your feedback on several key points as well as on the general = idea. > Also correct me brutally in case I'm wrong. >=20 > In order to not get confused in the following descriptions, I will = refer > to this project idea using the name `virtuned`, but there is really no > name for it yet (although an abbreviation for "Virtualization > Abstraction Definition and Hypervisor Delegation" would suit well, > IMHO). >=20 > Here are some common problems and use cases that virtuned could solve > (or help with). Don't take it as something that's impossible to solve > on your own, but rather something that could be de-duplicated from > multiple projects or "done right" instead of various hack-ish = solutions. >=20 > 1) Default devices/values >=20 > Libvirt itself must default to whatever values there were before any > particular element was introduced due to the fact that it strives to > keep the guest ABI stable. That means, for example, that it can't = just > add -vmcoreinfo option (for KASLR support) or magically add the = pvpanic > device to all QEMU machines, even though it would be useful, as that > would change the guest ABI. >=20 > For default values this is even more obvious. Let's say someone = figures > out some "pretty good" default values for various HyperV enlightenment > feature tunables. Libvirt can't magically change them, but each one = of > the projects building on top of it doesn't want to keep that list > updated and take care of setting them in every new XML. Some projects > don't even expose those to the end user as a knob, while others might. >=20 > One more thing could be automatically figuring out best values based = on > libosinfo-provided data. >=20 > 2) Policies >=20 > Lot of the time there are parts of the domain definition that need to = be > added, but nobody really cares about them. Sometimes it's enough to > have few templates, another time you might want to have a policy > per-scenario and want to combine them in various ways. For example = with > the data provided by point 1). >=20 > For example if you want PCI-Express, you need the q35 machine type, = but > you don't really want to care about the machine type. Or you want to > use SPICE, but you don't want to care about adding QXL. >=20 > What if some of these policies could be specified once (using some DSL > for example), and used by virtuned to merge them in a unified and > predictable way? >=20 > 3) Abstracting the XML >=20 > This is probably just usable for stateless apps, but it might happen > that some apps don't really want to care about the XML at all. They > just want an abstract view of the domain, possibly add/remove a device > and that's it. We could do that as well. I can't really tell how = much > of a demand there is for it, though. >=20 > 4) Identifying devices properly >=20 > In contrast to the previous point, stateful apps might have a problem > identifying devices after hotplug. For example, let's say you don't > care about the addresses and leave that up to libvirt. You hotplug a > device into the domain and dump the new XML of it. Depending on what > type of device it was, you might need to identify it based on = different > values. It could be <target dev=3D''/> for disks, <mac address=3D''/> = for > interfaces etc. For some devices it might not even be possible and = you > need to remember the addresses of all the previous devices and then > parse them just to identify that one device and then throw them away. >=20 > With new enough libvirt you could use the user aliases for that, but > turns out it's not that easy to use them properly anyway. Also the > aliases won't help users identify that device inside the guest. >=20 > <rant> > We really should've gone with new attribute for the user alias instead > of using an existing one, given how many problems that is causing. > </rant> >=20 > 5) Generating the right XML snippet for device hot-(un)plug >=20 > This is kind of related to some previous points. >=20 > When hot-plugging a device and creating an XML snippet for it, you = want > to keep the defaults from point 1) and policies from 2) in mind. Or > something related to the already existing domain which you can = describe > systematically. And adding something for identification (see previous > point). >=20 > Doing the hot-unplug is easy depending on how much information about > that device is saved by your application. The less you save about the > device (or show to the user in a GUI, if applicable) the harder it = might > be to generate an XML that libvirt will accept. Again, some problems > with this should be fixed in libvirt, some of them are easy to > workaround. But having a common ground that takes care of this should > help some projects. >=20 > Hot-unplug could be implemented just based on the alias. This is > something that would fit into libvirt as well. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > To mention some pre-existing solutions: >=20 > - I understand OpenStack has some really sensible and wisely chosen > and/or tested default values. >=20 > - I know KubeVirt has VirtualMachinePresets. That is something = closely > related to points 1) and 2). Also their abstraction of the XML might > be usable for point 3). >=20 > - There was an effort on creating policy based configuration of = libvirt > objects called libvirt-designer. This is closely related to points 2) > and 3). Unfortunately there was no much going on lately and part of > virt-manager repository has currently more features implemented with > the same ideas in mind, just not exported for public use. >=20 > We could utilize some of the above to various extents. >=20 > Let me know what you think and have a nice day. > Martin >=20 > --=20 > You received this message because you are subscribed to the Google = Groups "kubevirt-dev" group. > To unsubscribe from this group and stop receiving emails from it, send = an email to kubevirt-dev+unsubscribe(a)googlegroups.com. > To post to this group, send email to kubevirt-dev(a)googlegroups.com. > To view this discussion on the web visit = https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.GB23007%40wh= eatley. > For more options, visit https://groups.google.com/d/optout. --Apple-Mail=_6D569541-1CA3-4944-AFE7-86FD31122B7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" = class=3D"">cross-posting to the right list, by mistake a wrong ovirt = list was used originally<div class=3D""><div><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D"">Begin forwarded = message:</div><br class=3D"Apple-interchange-newline"><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;" class=3D""><span style=3D"font-family: = -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; = color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">From: = </b></span><span style=3D"font-family: -webkit-system-font, Helvetica = Neue, Helvetica, sans-serif;" class=3D"">Martin Kletzander <<a = href=3D"mailto:mkletzan@redhat.com" = class=3D"">mkletzan(a)redhat.com</a>><br class=3D""></span></div><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;" class=3D""><span style=3D"font-family: = -webkit-system-font, Helvetica Neue, Helvetica, sans-serif; = color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Subject: = </b></span><span style=3D"font-family: -webkit-system-font, Helvetica = Neue, Helvetica, sans-serif;" class=3D""><b class=3D"">[kubevirt-dev] = Project for profiles and defaults for libvirt domains</b><br = class=3D""></span></div><div style=3D"margin-top: 0px; margin-right: = 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span = style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, = sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">Date: = </b></span><span style=3D"font-family: -webkit-system-font, Helvetica = Neue, Helvetica, sans-serif;" class=3D"">20 March 2018 at 15:20:31 = CET<br class=3D""></span></div><div style=3D"margin-top: 0px; = margin-right: 0px; margin-bottom: 0px; margin-left: 0px;" class=3D""><span= style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, = sans-serif; color:rgba(0, 0, 0, 1.0);" class=3D""><b class=3D"">To: = </b></span><span style=3D"font-family: -webkit-system-font, Helvetica = Neue, Helvetica, sans-serif;" class=3D""><a = href=3D"mailto:libvir-list@redhat.com" = class=3D"">libvir-list(a)redhat.com</a>, <a = href=3D"mailto:openstack-dev@lists.openstack.org" = class=3D"">openstack-dev(a)lists.openstack.org</a>, <a = href=3D"mailto:ovirt-devel@redhat.com" = class=3D"">ovirt-devel(a)redhat.com</a>, <a = href=3D"mailto:kubevirt-dev@googlegroups.com" = class=3D"">kubevirt-dev(a)googlegroups.com</a>, <a = href=3D"mailto:virt-tools-list@redhat.com" = class=3D"">virt-tools-list(a)redhat.com</a>, <a = href=3D"mailto:cockpit-devel@lists.fedorahosted.org" = class=3D"">cockpit-devel(a)lists.fedorahosted.org</a><br = class=3D""></span></div><br class=3D""><div class=3D""><div class=3D"">Hi = everyone!<br class=3D""><br class=3D"">First of all sorry for such wide = distribution, but apparently that's the<br class=3D"">best way to make = sure we cooperate nicely.  So please be considerate as<br = class=3D"">this is a cross-post between huge amount of mailing lists.<br = class=3D""><br class=3D"">After some discussions with developers from = different projects that work<br class=3D"">with libvirt one cannot but = notice some common patterns and workarounds.<br class=3D"">So I set off = to see how can we make all our lives better and our coding<br = class=3D"">more effective (and maybe more fun as well).  If all = goes well we will<br class=3D"">create a project that will accommodate = most of the defaulting, policies,<br class=3D"">workarounds and other = common algorithms around libvirt domain<br class=3D"">definitions. =  And since early design gets you half way, I would like to<br = class=3D"">know your feedback on several key points as well as on the = general idea.<br class=3D"">Also correct me brutally in case I'm = wrong.<br class=3D""><br class=3D"">In order to not get confused in the = following descriptions, I will refer<br class=3D"">to this project idea = using the name `virtuned`, but there is really no<br class=3D"">name for = it yet (although an abbreviation for "Virtualization<br = class=3D"">Abstraction Definition and Hypervisor Delegation" would suit = well,<br class=3D"">IMHO).<br class=3D""><br class=3D"">Here are some = common problems and use cases that virtuned could solve<br class=3D"">(or = help with).  Don't take it as something that's impossible to = solve<br class=3D"">on your own, but rather something that could be = de-duplicated from<br class=3D"">multiple projects or "done right" = instead of various hack-ish solutions.<br class=3D""><br class=3D"">1) = Default devices/values<br class=3D""><br class=3D"">Libvirt itself must = default to whatever values there were before any<br class=3D"">particular = element was introduced due to the fact that it strives to<br = class=3D"">keep the guest ABI stable.  That means, for example, = that it can't just<br class=3D"">add -vmcoreinfo option (for KASLR = support) or magically add the pvpanic<br class=3D"">device to all QEMU = machines, even though it would be useful, as that<br class=3D"">would = change the guest ABI.<br class=3D""><br class=3D"">For default values = this is even more obvious.  Let's say someone figures<br = class=3D"">out some "pretty good" default values for various HyperV = enlightenment<br class=3D"">feature tunables.  Libvirt can't = magically change them, but each one of<br class=3D"">the projects = building on top of it doesn't want to keep that list<br class=3D"">updated= and take care of setting them in every new XML.  Some projects<br = class=3D"">don't even expose those to the end user as a knob, while = others might.<br class=3D""><br class=3D"">One more thing could be = automatically figuring out best values based on<br = class=3D"">libosinfo-provided data.<br class=3D""><br class=3D"">2) = Policies<br class=3D""><br class=3D"">Lot of the time there are parts of = the domain definition that need to be<br class=3D"">added, but nobody = really cares about them.  Sometimes it's enough to<br class=3D"">have= few templates, another time you might want to have a policy<br = class=3D"">per-scenario and want to combine them in various ways. =  For example with<br class=3D"">the data provided by point 1).<br = class=3D""><br class=3D"">For example if you want PCI-Express, you need = the q35 machine type, but<br class=3D"">you don't really want to care = about the machine type.  Or you want to<br class=3D"">use SPICE, = but you don't want to care about adding QXL.<br class=3D""><br = class=3D"">What if some of these policies could be specified once (using = some DSL<br class=3D"">for example), and used by virtuned to merge them = in a unified and<br class=3D"">predictable way?<br class=3D""><br = class=3D"">3) Abstracting the XML<br class=3D""><br class=3D"">This is = probably just usable for stateless apps, but it might happen<br = class=3D"">that some apps don't really want to care about the XML at = all.  They<br class=3D"">just want an abstract view of the domain, = possibly add/remove a device<br class=3D"">and that's it.  We could = do that as well.  I can't really tell how much<br class=3D"">of a = demand there is for it, though.<br class=3D""><br class=3D"">4) = Identifying devices properly<br class=3D""><br class=3D"">In contrast to = the previous point, stateful apps might have a problem<br = class=3D"">identifying devices after hotplug.  For example, let's = say you don't<br class=3D"">care about the addresses and leave that up = to libvirt.  You hotplug a<br class=3D"">device into the domain and = dump the new XML of it.  Depending on what<br class=3D"">type of = device it was, you might need to identify it based on different<br = class=3D"">values.  It could be <target dev=3D''/> for disks, = <mac address=3D''/> for<br class=3D"">interfaces etc.  For = some devices it might not even be possible and you<br class=3D"">need to = remember the addresses of all the previous devices and then<br = class=3D"">parse them just to identify that one device and then throw = them away.<br class=3D""><br class=3D"">With new enough libvirt you = could use the user aliases for that, but<br class=3D"">turns out it's = not that easy to use them properly anyway.  Also the<br = class=3D"">aliases won't help users identify that device inside the = guest.<br class=3D""><br class=3D""><rant><br class=3D"">We really = should've gone with new attribute for the user alias instead<br = class=3D"">of using an existing one, given how many problems that is = causing.<br class=3D""></rant><br class=3D""><br class=3D"">5) = Generating the right XML snippet for device hot-(un)plug<br class=3D""><br= class=3D"">This is kind of related to some previous points.<br = class=3D""><br class=3D"">When hot-plugging a device and creating an XML = snippet for it, you want<br class=3D"">to keep the defaults from point = 1) and policies from 2) in mind.  Or<br class=3D"">something = related to the already existing domain which you can describe<br = class=3D"">systematically.  And adding something for identification = (see previous<br class=3D"">point).<br class=3D""><br class=3D"">Doing = the hot-unplug is easy depending on how much information about<br = class=3D"">that device is saved by your application.  The less you = save about the<br class=3D"">device (or show to the user in a GUI, if = applicable) the harder it might<br class=3D"">be to generate an XML that = libvirt will accept.  Again, some problems<br class=3D"">with this = should be fixed in libvirt, some of them are easy to<br = class=3D"">workaround.  But having a common ground that takes care = of this should<br class=3D"">help some projects.<br class=3D""><br = class=3D"">Hot-unplug could be implemented just based on the alias. =  This is<br class=3D"">something that would fit into libvirt as = well.<br class=3D""><br = class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D<br class=3D""><br class=3D"">To mention some pre-existing = solutions:<br class=3D""><br class=3D"">- I understand OpenStack has = some really sensible and wisely chosen<br class=3D""> and/or tested = default values.<br class=3D""><br class=3D"">- I know KubeVirt has = VirtualMachinePresets.  That is something closely<br class=3D""> = related to points 1) and 2).  Also their abstraction of the XML = might<br class=3D""> be usable for point 3).<br class=3D""><br = class=3D"">- There was an effort on creating policy based configuration = of libvirt<br class=3D""> objects called libvirt-designer.  This is = closely related to points 2)<br class=3D""> and 3).  Unfortunately = there was no much going on lately and part of<br class=3D""> = virt-manager repository has currently more features implemented with<br = class=3D""> the same ideas in mind, just not exported for public use.<br = class=3D""><br class=3D"">We could utilize some of the above to various = extents.<br class=3D""><br class=3D"">Let me know what you think and = have a nice day.<br class=3D"">Martin<br class=3D""><br class=3D"">-- = <br class=3D"">You received this message because you are subscribed to = the Google Groups "kubevirt-dev" group.<br class=3D"">To unsubscribe = from this group and stop receiving emails from it, send an email to <a = href=3D"mailto:kubevirt-dev+unsubscribe@googlegroups.com" = class=3D"">kubevirt-dev+unsubscribe(a)googlegroups.com</a>.<br class=3D"">To= post to this group, send email to <a = href=3D"mailto:kubevirt-dev@googlegroups.com" = class=3D"">kubevirt-dev(a)googlegroups.com</a>.<br class=3D"">To view this = discussion on the web visit <a = href=3D"https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.GB23= 007%40wheatley" = class=3D"">https://groups.google.com/d/msgid/kubevirt-dev/20180320142031.G= B23007%40wheatley</a>.<br class=3D"">For more options, visit <a = href=3D"https://groups.google.com/d/optout" = class=3D"">https://groups.google.com/d/optout</a>.<br = class=3D""></div></div></blockquote></div><br = class=3D""></div></body></html>= --Apple-Mail=_6D569541-1CA3-4944-AFE7-86FD31122B7D--

1 0

UI is not coming up after pulled latest code from master
by Gobinda Das 22 Mar '18

22 Mar '18

Hi, UI keeps on loading and I can see below error in browser. webadmin-0.js:422 Wed Mar 21 14:59:47 GMT+530 2018 com.google.gwt.logging.client.LogConfiguration SEVERE: Possible problem with your *.gwt.xml module file. The compile time user.agent value (gecko1_8) does not match the runtime user.agent value (safari). Expect more errors. com.google.gwt.useragent.client.UserAgentAsserter$UserAgentAssertionError: Possible problem with your *.gwt.xml module file. The compile time user.agent value (gecko1_8) does not match the runtime user.agent value (safari). Expect more errors. at Unknown.L(webadmin-0.js) at Unknown.oj(webadmin-0.js) at Unknown.new pj(webadmin-0.js) at Unknown.nj(webadmin-0.js) at Unknown.nb(webadmin-0.js) at Unknown.qb(webadmin-0.js) at Unknown.eval(webadmin-0.js) -- Thanks, Gobinda

3 4

[VDSM] Remove fcraw build as gating
by Edward Haas 22 Mar '18

22 Mar '18

Hi All, Fcraw build on VDSM check-patch has been failing recently (again). fcraw cannot act as gating to the VDSM CI, as it is unstable (by definition). If there is a strong interest for some to track VDSM against this unstable distribution, it better be performed in parallel to the VDSM developing flow. With the current state, we are unable to trust the CI and it causes us to either overwrite its output (which I consider very bad) or just get stuck frequently. Could we please move this job to be triggered once a day as a nightly job and whoever is interested in its output to get notifications for it? Please. lets not make it a gating to VDSM development. Thanks, Edy.

3 3

[vdsm][maintainership] proposal for a new stable branch policy
by Francesco Romani 21 Mar '18

21 Mar '18

Hi all, Recently Milan, Petr and me discussed the state of ovirt.4.2, considering that release 4.2.2 is still pending and this prevents merging of patches in the sub-branch ovirt-4.2. We agreed we could improve the handling of the stable branch(es), in order to make the process smoother and more predictable. Currently, we avoid doing Z- branches (e.g. ovirt-4.2.2, ovirt-4.2.3...) as much as we can, to avoid the hassle of double-backporting patches to stable branch. However, if a release hits unexpected delay, this policy causes different hassles: the Y-branch (ovirt-4.2, ovirt-4.3) is effectively locked, so patches already queued and ready for next releases can't be merged and need to wait. The new proposed policy is the following: - we will keep working exactly as now until we hit a certain RC version. We choosed RC3, a rule of thumb made out of experience. - if RC3 is final, everyone's happy and things resume as usual - if RC3 is NOT final, we will branch out at RC3 -- from that moment on, patches for next version could be accepted on the Y-branch -- stabilization of the late Z version will continue on the Z-branch -- patches will be backported twice Example using made up numbers - We just released ovirt 4.3.1 - We are working on the ovirt-4.3 branch - The last tag is v4.30.10, from ovirt-4.3 branch - We accept patches for ovirt 4.3.2 on the ovirt-4.3 branch - We keep collecting patches, until we tag v4.30.11 (oVirt 4.3.2 RC 1). Tag is made from ovirt-4.3 branch. - Same for tags 4.30.12 - oVirt 4.3.2 RC 2 and 4.30.13 - oVirt 4.3.2 RC 3. Both tags are made from ovirt-4.3 branch. - Damn, RC3 is not final. We branch out ovirt-4.3.2 form branch ovirt-4.3 from the same commit pointed by tag 4.30.13 - Next tags (4.30.13.1) for ovirt 4.3.2 will be taken from the ovirt-4.3.2 branch I believe this approach will make predictable for everyone if and when the branch will be made, so when the patches could be merged and where. The only drawback I can see - and that I realized while writing the example - is the version number which can be awkward: v4.30.11 -> 4.3.2 RC1 v4.30.12 -> 4.3.2 RC2 v4.30.13 -> 4.3.2 RC3 v4.30.13.1 -> 4.3.2 RC4 ?!?! v4.30.13.5 -> 4.3.2 RC5 ?!?! Perhaps we should move to four versions digit? So we could have v4.30.11.0 -> 4.3.2 RC1 v4.30.11.1 -> 4.3.2 RC2 v4.30.11.2 -> 4.3.2 RC3 v4.30.11.3 -> 4.3.2 RC4 v4.30.11.4 -> 4.3.2 RC5 I don't see any real drawback in using 4-digit versions by default, besides a minor increase in complexity, which is balanced by more predictable and consistent versions. Plus, we already had 4-digit versions in Vdsm, so packaging should work just fine. Please share your thoughts, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

3 2

[vdsm] network test failure
by Francesco Romani 21 Mar '18

21 Mar '18

Hi all, we had a bogus failure on CI again, some network test failed and it seems totally unrelated to the patch being tested: http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/22410/conso… could someone please have a look? Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

4 4

[ OST Failure Report ] [ oVirt Master (Ovirt-ngine) ] [ 19-03-2018 ] [ 002_bootstrap.verify_notifier ]
by Dafna Ron 21 Mar '18

21 Mar '18

Hi, We had a failure in test 002_bootstrap.verify_notifier. I can't see anything wrong with the notifier and I don't think it should be related to the change that was reported. the test itself is looking for vdc_stop in messages which I do not indeed see but I am not sure what is the cause and how the reported change related to the failure. Can you please take a look? *Link and headline of suspected patches: * *core: USB in osinfo configuration depends on chipset - https://gerrit.ovirt.org/#/c/88777/ <https://gerrit.ovirt.org/#/c/88777/>Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6429/artifacts>(Relevant) error snippet from the log: <error>* *this is the error from *the api: Error Message Failed grep for VDC_STOP with code 1. Output: -------------------- >> begin captured logging << -------------------- lago.ssh: DEBUG: start task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine: lago.ssh: DEBUG: end task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine: lago.ssh: DEBUG: Running 1cce7c0c on lago-basic-suite-master-engine: grep VDC_STOP /var/log/messages lago.ssh: DEBUG: Command 1cce7c0c on lago-basic-suite-master-engine returned with 1 --------------------- >> end captured logging << --------------------- Stacktrace File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 1456, in verify_notifier 'Failed grep for VDC_STOP with code {0}. Output: {1}'.format(result.code, result.out) File "/usr/lib/python2.7/site-packages/nose/tools/trivial.py", line 29, in eq_ raise AssertionError(msg or "%r != %r" % (a, b)) 'Failed grep for VDC_STOP with code 1. Output: \n-------------------- >> begin captured logging << --------------------\nlago.ssh: DEBUG: start task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine:\nlago.ssh: DEBUG: end task:f1231b27-f796-406c-8618-17b0868725bc:Get ssh client for lago-basic-suite-master-engine:\nlago.ssh: DEBUG: Running 1cce7c0c on lago-basic-suite-master-engine: grep VDC_STOP /var/log/messages\nlago.ssh: DEBUG: Command 1cce7c0c on lago-basic-suite-master-engine returned with 1\n--------------------- >> end captured logging << ---------------------' *</error>*

3 4

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 19-03-2018 ] [002_bootstrap.add_instance_type ]
by Dafna Ron 21 Mar '18

21 Mar '18

Hi, We have a failure in test 002_bootstrap.add_instance_type. There seem to be a NullPointerException on template type which is causing this failure. The same change that was reported at the last failure is reported as the root cause for this failure as well, but I am not sure how it would cause this failure. Can you please check? *Link and headline of suspected patches: reported as failed: * *core: fix removal of vm-host device - https://gerrit.ovirt.org/#/c/89145/ <https://gerrit.ovirt.org/#/c/89145/>* *reported as root cause: * *core: USB in osinfo configuration depends on chipset - https://gerrit.ovirt.org/#/c/88777/ <https://gerrit.ovirt.org/#/c/88777/>* *Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431 <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6431/artifact…>(Relevant) error snippet from the log: <error>2018-03-19 04:59:01,040-04 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Lock Acquired to object 'EngineLock:{exclusiveLocks='[99a9dfb3-9a13-4595-a795-693493e722be=TEMPLATE, myinstancetype=TEMPLATE_NAME]', sharedLocks='[]'}'2018-03-19 04:59:01,087-04 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Running command: AddVmTemplateCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_TEMPLATE with role type USER2018-03-19 04:59:01,139-04 INFO [org.ovirt.engine.core.bll.storage.disk.CreateAllTemplateDisksCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Running command: CreateAllTemplateDisksCommand internal: true.2018-03-19 04:59:01,205-04 INFO [org.ovirt.engine.core.utils.transaction.TransactionSupport] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] transaction rolled back2018-03-19 04:59:01,205-04 ERROR [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command 'org.ovirt.engine.core.bll.AddVmTemplateCommand' failed: null2018-03-19 04:59:01,205-04 ERROR [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Exception: java.lang.NullPointerException at org.ovirt.engine.core.bll.utils.EmulatedMachineUtils.getEffective(EmulatedMachineUtils.java:30) [bll.jar:] at org.ovirt.engine.core.bll.utils.EmulatedMachineUtils.getEffectiveChipset(EmulatedMachineUtils.java:21) [bll.jar:] at org.ovirt.engine.core.bll.utils.VmDeviceUtils.updateUsbSlots(VmDeviceUtils.java:744) [bll.jar:] at org.ovirt.engine.core.bll.utils.VmDeviceUtils.copyVmDevices(VmDeviceUtils.java:1519) [bll.jar:] at org.ovirt.engine.core.bll.utils.VmDeviceUtils.copyVmDevices(VmDeviceUtils.java:1565) [bll.jar:] at org.ovirt.engine.core.bll.AddVmTemplateCommand.lambda$executeCommand$4(AddVmTemplateCommand.java:362) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:202) [utils.jar:] at org.ovirt.engine.core.bll.AddVmTemplateCommand.executeCommand(AddVmTemplateCommand.java:345) [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:468) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:450) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:403) [bll.jar:] at sun.reflect.GeneratedMethodAccessor149.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) at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:92) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.interceptorChainCompleted(WeldInvocationContext.java:98) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:117) [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.GeneratedMethodAccessor69.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.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:108) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:82) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] at org.jboss.as.weld.interceptors.EjbComponentInterceptorSupport.delegateInterception(EjbComponentInterceptorSupport.java:60) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:76) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:88) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor66.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.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422):* *End of error: * at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_161] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_161] 2018-03-19 04:59:01,234-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Compiled stored procedure. Call string is [{call get_entity_snapshot_by_command_id(?)}] 2018-03-19 04:59:01,234-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] SqlCall for procedure [get_entity_snapshot_by_command_id] compiled 2018-03-19 04:59:01,239-04 INFO [org.ovirt.engine.core.bll.CommandCompensator] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command [id=a7a51354-ae84-4109-a55e-b27558afbf2a]: Compensating NEW_ENTITY_ID of org.ovirt.engine.core.common.businessentities.VmTemplate; snapshot: 99a9dfb3-9a13-4595-a795-693493e722be. 2018-03-19 04:59:01,278-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] EVENT_ID: USER_ADD_VM_TEMPLATE_FAILURE(36), Failed creating Template myinstancetype. 2018-03-19 04:59:01,295-04 INFO [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] Lock freed to object 'EngineLock:{exclusiveLocks='[99a9dfb3-9a13-4595-a795-693493e722be=TEMPLATE, myinstancetype=TEMPLATE_NAME]', sharedLocks='[]'}' 2018-03-19 04:59:01,295-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-5) [5a890b17-51ec-4398-8d64-82cc71939e6e] method: runAction, params: [AddVmTemplate, AddVmTemplateParameters:{commandId='a7a51354-ae84-4109-a55e-b27558afbf2a', user='admin', commandType='AddVmTemplate'}], timeElapsed: 301ms 2018-03-19 04:59:01,301-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-5) [] Operation Failed: [Internal Engine Error] 2018-03-19 04:59:01,547-04 INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-83) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command 'AddVmTemplate' id: 'a7a51354-ae84-4109-a55e-b27558afbf2a' execution didn't complete, not proceeding to perform the next operation 2018-03-19 04:59:01,547-04 INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-83) [5a890b17-51ec-4398-8d64-82cc71939e6e] Command 'AddVmTemplate' id: 'a7a51354-ae84-4109-a55e-b27558afbf2a' child commands '[8484f4d2-9ddf-48bd-9877-7c99ef555255]' executions were completed, status 'FAILED' 2018-03-19 04:59:01,581-04 INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-83) [db5dd3dd-8b48-4647-a02d-723fcd6a7dda] Command 'ImportRepoImage' (id: 'a6475141-53ef-4ecd-bc17-ee8eae168dc7') waiting on child command id: '528fde29-9b5b-4a90-b62a-606fac3cd6a6' type:'DownloadImage' to complete 2018-03-19 04:59:02,363-04 DEBUG [org.ovirt.otopi.dialog.MachineDialogParser] (VdsDeploy) [665e1c35] Got: ***L:INFO Yum install: 349/515: gdisk-0.8.6-5.el7.x86_64 2018-03-19 04:59:02,364-04 DEBUG [org.ovirt.otopi.dialog.MachineDialogParser] (VdsDeploy) [665e1c35] nextEvent: Log INFO Yum install: 349/515: gdisk-0.8.6-5.el7.x86_64 2018-03-19 04:59:02,570-04 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [665e1c35] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host lago-basic-suite-master-host-1. Yum install: 349/515: gdisk-0.8.6-5.el7.x86_64. 2018-03-19 04:59:02,666-04 ERROR [org.ovirt.engine.core.bll.AddVmTemplateCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-86) [5a890b17-51ec-4398-8d64-82cc71939e6e] Ending command 'org.ovirt.engine.core.bll.AddVmTemplateCommand' with failure. *</error>*

2 4

[ OST Failure Report ] [ oVirt 4.2 (ovirt-engine) ] [ 19-03-2018 ] [ 004_basic_sanity.verify_vm_import ]
by Dafna Ron 20 Mar '18

20 Mar '18

Hi, We have a failed change on test 004_basic_sanity.verify_vm_import. I can't see anything in the logs that suggests there was a problem with the import and the error in the junit also suggest this can possibly be in the api version. can you please check the issue? *Link and headline of suspected patches: * *core: Call endAction() of all child commands in ImportVmCommand - https://gerrit.ovirt.org/#/c/89165/ <https://gerrit.ovirt.org/#/c/89165/>Link to Job:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362 <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362>Link to all logs:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362/artifa… <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1362/artifact/ex…>(Relevant) error snippet from the log: <error>2018-03-19 11:01:59,679-04 INFO [org.ovirt.engine.core.bll.exportimport.ImportVmCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-22) [] Lock freed to object 'EngineLock:{exclusiveLocks='[imported_vm=VM_NAME, 3494a94b-c253-440b-a6cb-c4c818b19ae1=VM]', sharedLocks='[cc4255e8-8e1d-4608-a3fe-a2096ed4e9f9=REMOTE_VM]'}'* Error Message False != True after 180 seconds Stacktrace Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 78, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test-scenarios/004_basic_sanity.py", line 596, in verify_vm_import lambda: vm_service.get().status == types.VmStatus.DOWN File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 267, in assert_true_within_short assert_equals_within_short(func, True, allowed_exceptions) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 251, in assert_equals_within_short func, value, SHORT_TIMEOUT, allowed_exceptions=allowed_exceptions File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 237, in assert_equals_within '%s != %s after %s seconds' % (res, value, timeout) AssertionError: False != True after 180 seconds *</error>*

2 3

Bug 1557532 - CVE-2018-1000134 unboundid-ldapsdk: Incorrect Access Control vulnerability in process function in SimpleBindRequest class [fedora-all]
by Sandro Bonazzola 19 Mar '18

19 Mar '18

Hi, before I start building the same package for CentOS Virt SIG, please help testing the new 4.0.5 build on Fedora and ensure aaa-ldap package still work with the new build. If it works for you. please give karma to the build to allow it to be released to stable. unboundid-ldapsdk-4.0.5-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-c188d3f09a unboundid-ldapsdk-4.0.5-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0a473d6e7b unboundid-ldapsdk-4.0.5-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e8635ed222 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

[ OST Failure Report ] [ oVirt Master (cockpit-ovirt) ] [ 15-03-2018 ] [ 098_ovirt_provider_ovn.use_ovn_provider ]
by Dafna Ron 19 Mar '18

19 Mar '18

Hi, We have a failure on master for test 098_ovirt_provider_ovn.use_ovn_provider in project cockpit-ovirt. This seems to be a race because object is locked. also, the actual failure is logged as WARN and not ERROR. I don't think the patch is actually related to the failure but I think the test should be fixed. can you please review to make sure we do not have an actual regression and let me know if we need to open a bz to fix the test? *Link and headline of suspected patches: * *https://gerrit.ovirt.org/#/c/89020/2 <https://gerrit.ovirt.org/#/c/89020/2> - * *wizard: Enable scroll on start page for low-res screensLink to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374 <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6374/artifacts>(Relevant) error snippet from the log: <error>2018-03-15 10:05:00,160-04 DEBUG [org.ovirt.engine.core.sso.servlets.OAuthTokenInfoServlet] (default task-10) [] Sending json response2018-03-15 10:05:00,160-04 DEBUG [org.ovirt.engine.core.sso.utils.TokenCleanupUtility] (default task-10) [] Not cleaning up expired tokens2018-03-15 10:05:00,169-04 INFO [org.ovirt.engine.core.bll.provider.network.SyncNetworkProviderCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-90) [789edb23] Lock Acquired to object 'EngineLock:{exclusiveLocks='[c38a67ec-0b48-4e6f-be85-70c700df5483=PROVIDER]', sharedLocks=''}'2018-03-15 10:05:00,184-04 INFO [org.ovirt.engine.core.bll.provider.network.SyncNetworkProviderCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-90) [789edb23] Running command: SyncNetworkProviderCommand internal: true.2018-03-15 10:05:00,228-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] Compiled stored procedure. Call string is [{call getdcidbyexternalnetworkid(?)}]2018-03-15 10:05:00,228-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] SqlCall for procedure [GetDcIdByExternalNetworkId] compiled2018-03-15 10:05:00,229-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] method: runQuery, params: [GetAllExternalNetworksOnProvider, IdQueryParameters:{refresh='false', filtered='false'}], timeElapsed: 353ms2018-03-15 10:05:00,239-04 INFO [org.ovirt.engine.core.bll.network.dc.AddNetworkCommand] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[network_1=NETWORK, c38a67ec-0b48-4e6f-be85-70c700df5483=PROVIDER]', sharedLocks=''}'2018-03-15 10:05:00,239-04 WARN [org.ovirt.engine.core.bll.network.dc.AddNetworkCommand] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] Validation of action 'AddNetwork' failed for user admin@internal-authz. Reasons: VAR__TYPE__NETWORK,VAR__ACTION__ADD,ACTION_TYPE_FAILED_PROVIDER_LOCKED,$providerId c38a67ec-0b48-4e6f-be85-70c700df54832018-03-15 10:05:00,240-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-13) [e1328379-17b7-49f8-beb2-cf8331784828] method: runAction, params: [AddNetwork, AddNetworkStoragePoolParameters:{commandId='61b365ec-27c1-49af-ad72-f907df8befcd', user='null', commandType='Unknown'}], timeElapsed: 10ms2018-03-15 10:05:00,250-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [Cannot add Network. Related operation on provider with the id c38a67ec-0b48-4e6f-be85-70c700df5483 is currently in progress. Please try again later.]2018-03-15 10:05:00,254-04 DEBUG [org.ovirt.engine.core.utils.servlet.LocaleFilter] (default task-14) [] Incoming locale 'en-US'. Filter determined locale to be 'en-US'2018-03-15 10:05:00,254-04 DEBUG [org.ovirt.engine.core.sso.servlets.OAuthTokenServlet] (default task-14) [] Entered OAuthTokenServlet Query String: null, Parameters : password = ***, grant_type = password, scope = ovirt-app-api ovirt-ext=token-info:validate, username = admin@internal, </error>*

3 7

OST Failure - Weekly update [09/03/2018-16/03/2018]
by Dafna Ron 16 Mar '18

16 Mar '18

Hello, I would like to update on this week's failures and OST current status. We had a very eventful week with 2 regressions identified by OST 1. On 11-03-2018 the CI team reported a regression in project ovirt-engine. The change reported was https://gerrit.ovirt.org/#/c/88738/ - db: add func to turn table columns to empty string. This caused a failure in both master and 4.2 in OST but was also identified to be an issue in 4.1. The fix for all 3 versions can be tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1554377 and was submitted on 15-03-2018. I hope that in future we would resolve such regression much faster as it took us 5 days to resolve this issue but I would also like to thank all that helped to resolve it once the issue was investigated more deeply. 2. on 13-03-2018 we found a regression in otopi: *core: Use python3 when possible- https://gerrit.ovirt.org/#/c/87276/ <https://gerrit.ovirt.org/#/c/87276/>* *The fix was* submitted *on the same day **https://gerrit.ovirt.org/88931 <https://gerrit.ovirt.org/88931> - **spec: Package otopi-functions* We also had 1 configuration related issue which was fixed by the CI team and we had failed build-artifacts, mostly in fc27. this was due to the change in fedora to not allow the use of yum and had to be solved by the projects making minor patch changes. *Below you can see the chart for this week's resolved issues but cause of failure:*Code = regression of working components/functionalities Configurations = package related issues Other = failed build artifacts Infra = infrastructure/OST/Lago related issues *Below is a chart of resolved failures based on ovirt version* *Below is a chart showing failures by suite type: * Thank you, Dafna

1 0

UI plugin API updates
by Vojtech Szocs 15 Mar '18

15 Mar '18

Dear community, the UI plugin API will be updated to reflect recent oVirt web administration UI design changes. The relevant patch is already merged in master branch [1] and the associated BZ [2] is targeted for 4.3 release. *What's new* Two new API functions, addPrimaryMenuContainer and addSecondaryMenuPlace, allow you to add custom secondary menu items to the vertical navigation menu. You can target both existing (core) and custom primary menu items when adding secondary ones. *What's changed* Some API functions were renamed to stay consistent with current UI design, i.e. reflecting the absence of "main" and "sub" tabs. - addMainTab => addPrimaryMenuPlace - addSubTab => addDetailPlace - setTabContentUrl => setPlaceContentUrl - setTabAccessible => setPlaceAccessible - addMainTabActionButton => addMenuPlaceActionButton - addSubTabActionButton => addDetailPlaceActionButton You can still use the original functions mentioned above, but doing so will yield a warning in the browser console, for example: *addMainTab is deprecated, please use addPrimaryMenuPlace instead.* In addition, for functions that used to deal with "main" or "sub" tabs, the options object no longer supports alignRight (boolean) parameter. That's because PatternFly tabs widget [3] expects all tabs to be aligned next to each other, flowing from left to right. We'll be updating the UI plugins feature page shortly to reflect all the changes. [1] https://gerrit.ovirt.org/#/c/88690/ [2] https://bugzilla.redhat.com/1553902 [3] http://www.patternfly.org/pattern-library/widgets/#tabs Regards, Vojtech

1 0

[ OST Failure Report ] [ oVirt 4.2 ] [ 002_bootstrap.update_default_cluster ]
by Daniel Belenky 15 Mar '18

15 Mar '18

Hi, The following patch failed to pass OST: https://gerrit.ovirt.org/#/c/88738/2 Link to failed build: here <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1181/> Link to all logs: here <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1181/artifact/ex…> Error snippet from engine.log <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1181/artifact/ex…> : 2018-03-11 06:10:58,521-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-14) [] Operation Failed: [Cannot edit Cluster. The chosen CPU is not supported.] Thanks, -- DANIEL BELENKY RHV DEVOPS

6 16

[ OST Failure Report ] [ oVirt Master (otopi) ] [ 13-03-2018 ] [ 002_bootstrap.verify_add_hosts + 002_bootstrap.add_hosts ]
by Dafna Ron 14 Mar '18

14 Mar '18

Hi, CQ reported failure on both basic and upgrade suites in otpi project. *Link and headline of suspected patches: * *core: Use python3 when possible- https://gerrit.ovirt.org/#/c/87276/ <https://gerrit.ovirt.org/#/c/87276/>Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6285/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6285/>Link to all logs:* http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6285/artifact… *(Relevant) error snippet from the log: <error> at org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.lambda$executeCommand$2(AddVdsCommand.java:217) [bll.jar:] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:96) [utils.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_161] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_161] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_161] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_161] at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) [javax.enterprise.concurrent-1.0.jar:] at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78)2018-03-13 09:22:40,287-04 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [7e847b89] Error during deploy dialog2018-03-13 09:22:40,288-04 DEBUG [org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter] (default task-25) [] Entered SsoRestApiAuthFilter2018-03-13 09:22:40,288-04 DEBUG [org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter] (default task-25) [] SsoRestApiAuthFilter authenticating with sso2018-03-13 09:22:40,288-04 DEBUG [org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter] (default task-25) [] SsoRestApiAuthFilter authenticating using BEARER header2018-03-13 09:22:40,290-04 DEBUG [org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter] (default task-25) [] SsoRestApiAuthFilter successfully authenticated using BEARER header2018-03-13 09:22:40,290-04 DEBUG [org.ovirt.engine.core.aaa.filters.SsoRestApiNegotiationFilter] (default task-25) [] Entered SsoRestApiNegotiationFilter2018-03-13 09:22:40,292-04 DEBUG [org.ovirt.engine.core.aaa.filters.SsoRestApiNegotiationFilter] (default task-25) [] SsoRestApiNegotiationFilter Not performing Negotiate Auth2018-03-13 09:22:40,297-04 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-2) [7e847b89] Error during host lago-basic-suite-master-host-1 install2018-03-13 09:22:40,311-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-2) [7e847b89] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host lago-basic-suite-master-host-1: Unexpected error during execution: /tmp/ovirt-8LoLZqxUw8/otopi: line 29: /tmp/ovirt-8LoLZqxUw8/otopi-functions: No such file or directory.2018-03-13 09:22:40,311-04 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-2) [7e847b89] Error during host lago-basic-suite-master-host-1 install, preferring first exception: Unexpected connection termination2018-03-13 09:22:40,311-04 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-2) [7e847b89] Host installation failed for host '9cca064c-4034-4428-9cc5-d4e902083dfe', 'lago-basic-suite-master-host-1': Unexpected connection termination</error>*

4 4

ovirt-system-tests hackathon report
by Sandro Bonazzola 13 Mar '18

13 Mar '18

4 people accepted calendar invite: - Devin A. Bougie - Francesco Romani - Jiri Belka - suporte, logicworks 4 people tentatively accepted calendar invite: - Amnon Maimon - Andreas Bleischwitz - Arnaud Lauriou - Stephen Pesini 2 mailing lists accepted calendar invite: users(a)ovirt.org, devel(a)ovirt.org (don't ask me how) so I may have missed someone in above list 4 patches got merged: Add check for host update to the 1st host. <https://gerrit.ovirt.org/88767> Merged Yaniv Kaul <https://gerrit.ovirt.org/#/q/owner:ykaul%2540redhat.com+status:merged> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master (add_upgrade_check) <https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-system-tests+branc…> 4:10 PM basic-suite-master: add vnic_profile_mappings to register vm <https://gerrit.ovirt.org/87438> Merged Eitan Raviv <https://gerrit.ovirt.org/#/q/owner:eraviv%2540redhat.com+status:merged> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master (register-template-vnic-mapping) <https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-system-tests+branc…> 2:50 PM Revert "ovirt-4.2: Skipping 002_bootstrap.update_default_cluster" <https://gerrit.ovirt.org/88881> Merged Eyal Edri <https://gerrit.ovirt.org/#/q/owner:eedri%2540redhat.com+status:merged> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-system-tests+branc…> 11:36 AM seperate 4.2 tests and utils from master <https://gerrit.ovirt.org/88878> Merged Eyal Edri <https://gerrit.ovirt.org/#/q/owner:eedri%2540redhat.com+status:merged> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:merged+project:ovirt-system-tests+branc…> 11:35 AM 13 patches has been pushed / reviewed / rebased Add gdeploy to ovirt-4.2.repo <https://gerrit.ovirt.org/88929> Daniel Belenky <https://gerrit.ovirt.org/#/q/owner:dbelenky%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 4:53 PM Cleanup of test code - next() replaced with any() <https://gerrit.ovirt.org/88928> Martin Sivák <https://gerrit.ovirt.org/#/q/owner:msivak%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 4:51 PM Add network queues custom property and use it in the vnic profile for VM0 <https://gerrit.ovirt.org/88829> Yaniv Kaul <https://gerrit.ovirt.org/#/q/owner:ykaul%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master (multi_queue_config) <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 4:49 PM new suite: he-basic-iscsi-suite-master <https://gerrit.ovirt.org/85838> Yuval Turgeman <https://gerrit.ovirt.org/#/q/owner:yturgema%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master (he-basic-iscsi-suite-master) <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 4:47 PM Collect host-deploy bundle from the engine <https://gerrit.ovirt.org/88925> Yedidyah Bar David <https://gerrit.ovirt.org/#/q/owner:didi%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 4:41 PM network-suite-master: Make openstack_client_config fixture available to all ... <https://gerrit.ovirt.org/88029> Merge Conflict Marcin Mirecki <https://gerrit.ovirt.org/#/q/owner:mmirecki%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 3:39 PM new suite: he-basic-ng-ansible-suite-master <https://gerrit.ovirt.org/88901> Sandro Bonazzola <https://gerrit.ovirt.org/#/q/owner:sbonazzo%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master (he-basic-ng-ansible-suite-master) <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 3:37 PM Enable and move additional tests to 002 <https://gerrit.ovirt.org/88711> Yaniv Kaul <https://gerrit.ovirt.org/#/q/owner:ykaul%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master (move_more_to_002) <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 3:08 PM common: ovirt-4.2.repo <https://gerrit.ovirt.org/88904> Sandro Bonazzola <https://gerrit.ovirt.org/#/q/owner:sbonazzo%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 2:34 PM networking: Introducing test_stateless_vm_duplicate_mac_addr_vnic_does_not_be... <https://gerrit.ovirt.org/86946> Leon Goldberg <https://gerrit.ovirt.org/#/q/owner:lgoldber%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 2:08 PM hc: Updating gdeploy conf to create vdo volumes <https://gerrit.ovirt.org/88899> Sahina Bose <https://gerrit.ovirt.org/#/q/owner:sabose%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 12:55 PM master: add USB to the sanity VM <https://gerrit.ovirt.org/88731> Michal Skrivanek <https://gerrit.ovirt.org/#/q/owner:michal.skrivanek%2540redhat.com+status:o…> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 12:54 PM Test hosted-engine cleanup <https://gerrit.ovirt.org/88331> Yedidyah Bar David <https://gerrit.ovirt.org/#/q/owner:didi%2540redhat.com+status:open> ovirt-system-tests <https://gerrit.ovirt.org/#/projects/ovirt-system-tests,dashboards/default> master <https://gerrit.ovirt.org/#/q/status:open+project:ovirt-system-tests+branch:…> 9:39 AM Feedback from the event: - "if we want to add many more tests to OST, and I think we do, we need to do some change there to allow that. Current framework is simply not scalable enough" - not joining the hackathon because "I'd be like an elephant in a porcelain shop" - "I'm not sure I'm OK with the flood of suites that we have - the more we have, the harder it is to sync and maintain but more importantly - to run." - "We can't keep adding new suite for each parameter we want to test, it adds overhead to monitoring, resources and maintenance." - invite wasn't clear enough. I found people on #ovirt on Freenode and on Red Hat IRC servers and redirected them to OFTC IRC server (my fault, hopefully managed to workaround it by talking to people) Lessons learned: - Calendar invites to mailing lists doesn't work well, need a different way to track mailing list members joining the events. - Invites needs to be pedantic on how to join the event, not leaving space for interpretation and misunderstanding. - We need a contribution guide to ovirt-system-test: we need to make people comfortable in trying to add a new test and we need to ensure that we won't reject a day of work because the patch doesn't match core contributors plannings on number of suites, resources and so on - The ovirt-system-tests check patch script is not good enough. It triggers too many sequential suites on every single patch pushed, and fails due to timeout taking more than 6 hours to complete. - The way ovirt-system-test collects rpms from defined repos is not smart enough: it doesn't take the latest version of a given package, just the first found in sequential order of the repos, Thanks everyone who participated to the event! if you have time please continue improving ovirt-system-test even if today event is almost completed! -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

4 3

Heads up: dropping fcraw jobs from jenkins
by Sandro Bonazzola 13 Mar '18

13 Mar '18

Following today call, I'm going to push a patch for dropping all rawhide jobs from jenkins. This should help avoiding distractions and reducing patches blocked by rawhide issues. -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

5 8

qemu-kvm-ev-2.9.0-16.el7_4.14.1 has been released
by Sandro Bonazzola 12 Mar '18

12 Mar '18

Hi, qemu-kvm-ev-2.9.0-16.el7_4.14.1 <http://cbs.centos.org/koji/buildinfo?buildID=22232> has been tagged for release and should land on mirrors.centos.org on Monday, March 12th 2018. Here's the ChangeLog: * Thu Mar 08 2018 Sandro Bonazzola <sbonazzo(a)redhat.com> - ev-2.9.0-16.el7_4.14.1 - Removing RH branding from package name * Thu Jan 18 2018 Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.14 - kvm-fw_cfg-fix-memory-corruption-when-all-fw_cfg-slots-a.patch [bz#1534649] - kvm-mirror-Fix-inconsistent-backing-AioContext-for-after.patch [bz#1535125] - Resolves: bz#1534649 (Qemu crashes when all fw_cfg slots are used [rhel-7.4.z]) - Resolves: bz#1535125 (Mirror jobs for drives with iothreads make QEMU to abort with "block.c:1895: bdrv_attach_child: Assertion `bdrv_get_aio_context(parent_bs) == bdrv_get_aio_context(child_bs)' failed." [rhel-7.4.z]) Regards, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

OST Failure - Weekly update [03/03/2018-09/03/2018]
by Dafna Ron 09 Mar '18

09 Mar '18

Hello, I would like to update on this week's failures and OST current status. We had a few failure this week: 1. A change in OST caused a failure in one of the tests. this was due to using a 4.3 SDK feature which is not available in the current SDK version. The change was https://gerrit.ovirt.org/#/c/84338 - https://gerrit.ovirt.org/#/c/84338/ We reverted the change: https://gerrit.ovirt.org/#/c/88441/ However, this merge actually exposed an issue in the vdsm logs which report guest agent errors. bug was opened: https://bugzilla.redhat.com/show_bug.cgi?id=1553893 2. We discovered that there was a syntax error in 'release_branches' in ovirt-ansible. we re-merged after fixing the issue - Thanks you Barak/Sandro and Ondra for investigating and fixing the issue. This solved issues that were caused by running tests from stable older ansible packages. 3. fcraw build-artifacts jobs were removed since they were causing changes to fail running on cq. it was decided that its better to disable those jobs for now. 4. we have a second failure in build-artifacts for fc27 which caused several changes that were merged in cockpit-ovirt to fail. Thank you Douglas for acting quickly to resolve the issue. *Below you can see the chart for this week's resolved issues but cause of failure: * Code = regression of working components/functionalities Configurations = package related issues Other = failed build artifacts Infra = infrastructure/OST/Lago related issues *Below is a chart of resolved failures based on ovirt version* *Below is a chart showing failures by suite type: * Thank you, Dafna

2 1

[ OST Failure Report ] [ oVirt 4.2 (ovirt-engine) ] [ 04-03-2018 ] [ 004_basic_sanity.disk_operations ]
by Daniel Belenky 09 Mar '18

09 Mar '18

Hi, The following test failed OST: 004_basic_sanity.disk_operations. Link to suspected patch: https://gerrit.ovirt.org/c/88404/ Link to the failed job: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1019/ Link to all test logs: - engine <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1019/artifact/ex…> - host 0 <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1019/artifact/ex…> - host 1 <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1019/artifact/ex…> Error snippet from engine: 2018-03-04 09:50:14,823-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-12) [] EVENT_ID: VM_DOWN_ERROR(119), VM vm2 is down with error. Exit message: Lost connection with qemu process. Error snippet from host: Mar 4 09:56:27 lago-basic-suite-4-2-host-1 libvirtd: 2018-03-04 14:56:27.831+0000: 1189: error : qemuDomainAgentAvailable:6010 : Guest agent is not responding: QEMU guest agent is not connected Thanks, -- DANIEL BELENKY RHV DEVOPS

6 7

Updated invitation: oVirt System Test Hackathon @ Tue Mar 13, 2018 (devel@ovirt.org)
by sbonazzo＠redhat.com 08 Mar '18

08 Mar '18

This event has been changed. Title: oVirt System Test Hackathon Please join us in an ovirt-system-tests hackathon pushing new tests and improving existing ones for testing Hosted Engine.Git repo is available: https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=summaryIntegrati…, Node and CI team will be available for helping in the effort and reviewing patches.Here's a public trello board tracking the efforts: https://trello.com/b/Pp76YoRL (changed) When: Tue Mar 13, 2018 Where: #ovirt IRC channel Calendar: devel(a)ovirt.org Who: * sbonazzo(a)redhat.com - organizer * devel(a)ovirt.org * users(a)ovirt.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MDhuZTY5bXRxbGo0cnNmM… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account devel(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Invitation: oVirt System Test Hackathon @ Tue Mar 13, 2018 (devel@ovirt.org)
by sbonazzo＠redhat.com 08 Mar '18

08 Mar '18

You have been invited to the following event. Title: oVirt System Test Hackathon Please join us in an ovirt-system-tests hackathon pushing new tests and improving existing ones for testing Hosted Engine. Git repo is available: https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=summary Integration, Node and CI team will be available for helping in the effort and reviewing patches. When: Tue Mar 13, 2018 Where: #ovirt IRC channel Calendar: devel(a)ovirt.org Who: * sbonazzo(a)redhat.com - organizer * devel(a)ovirt.org * users(a)ovirt.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MDhuZTY5bXRxbGo0cnNmM… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account devel(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

he-basic-ansible-suite-master and he-basic-suite-master
by Sandro Bonazzola 08 Mar '18

08 Mar '18

Hi, I'm looking at diffs between he-basic-ansible-suite-master and he-basic-suite-master in oVirt Sytem Test. Since we are now defaulting to the ansible deployment, aren't these 2 suites substantially testing the same flow? Can we drop one of them? Or should we change the non ansible suite to enforce using legacy otopi flow? Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 2

[ OST Failure Report ] [ oVirt 4.2 (ovirt-hosted-engine-setup) ] [ 08-03-2018 ] [ 004_basic_sanity.run_vms ]
by Dafna Ron 08 Mar '18

08 Mar '18

Hi, We have a failed test on ovirt-hosted-engine-setup basic suite. We failed to run a vm with internal engine error. *Link and headline of suspected patches: Add engine fqdn to inventory and allow dynamic inventory scripts - https://gerrit.ovirt.org/#/c/88622/ <https://gerrit.ovirt.org/#/c/88622/>Link to Job:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1064/ <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1064/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1064/artifa… <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1064/artifact/>(Relevant) error snippet from the log: <error>2018-03-07 17:03:38,374-05 INFO [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] Running command: RunVmOnceCommand internal: false. Entities affected : ID: 634c6a46-d057-4509-be3b-710716cbd56d Type: VMAction group RUN_VM with role type USER, ID: 634c6a46-d057-4509-be3b-710716cbd56d Type: VMAction group EDIT_ADMIN_VM_PROPERTIES with role type ADMIN2018-03-07 17:03:38,379-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] method: getVmManager, params: [634c6a46-d057-4509-be3b-710716cbd56d], timeElapsed: 5ms2018-03-07 17:03:38,391-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] method: getAllForClusterWithStatus, params: [14cad400-49a0-44e0-ab15-9da778f08082, Up], timeElapsed: 7ms2018-03-07 17:03:38,408-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] method: getVdsManager, params: [8ef2f490-1b76-46e0-b9fe-f3412a36e03b], timeElapsed: 0ms2018-03-07 17:03:38,419-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.CustomSQLErrorCodeSQLExceptionTranslator] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] Translating SQLException with SQL state '23505', error code '0', message [ERROR: duplicate key value violates unique constraint "name_server_pkey" Detail: Key (dns_resolver_configuration_id, address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already exists. Where: SQL statement "INSERT INTO name_server( address, position, dns_resolver_configuration_id) VALUES ( v_address, v_position, v_dns_resolver_configuration_id)"PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3 at SQL statement]; SQL was [{call insertnameserver(?, ?, ?)}] for task [CallableStatementCallback]2018-03-07 17:03:38,420-05 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] Command 'org.ovirt.engine.core.bll.RunVmOnceCommand' failed: CallableStatementCallback; SQL [{call insertnameserver(?, ?, ?)}]; ERROR: duplicate key value violates unique constraint "name_server_pkey" Detail: Key (dns_resolver_configuration_id, address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already exists. Where: SQL statement "INSERT INTO name_server( address, position, dns_resolver_configuration_id) VALUES ( v_address, v_position, v_dns_resolver_configuration_id)"PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "name_server_pkey" Detail: Key (dns_resolver_configuration_id, address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already exists. Where: SQL statement "INSERT INTO name_server( address, position, dns_resolver_configuration_id) VALUES ( v_address, v_position, v_dns_resolver_configuration_id)"PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3 at SQL statement2018-03-07 17:03:38,420-05 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] Exception: org.springframework.dao.DuplicateKeyException: CallableStatementCallback; SQL [{call insertnameserver(?, ?, ?)}]; ERROR: duplicate key value violates unique constraint "name_server_pkey" Detail: Key (dns_resolver_configuration_id, address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already exists. Where: SQL statement "INSERT INTO name_server( address, position, dns_resolver_configuration_id) VALUES (: v_address, v_position, v_dns_resolver_configuration_id)"PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3 at SQL statement; nested exception is org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "name_server_pkey" Detail: Key (dns_resolver_configuration_id, address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already exists. Where: SQL statement "INSERT INTO name_server( address, position, dns_resolver_configuration_id) VALUES ( v_address, v_position, v_dns_resolver_configuration_id)"PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3 at SQL statement at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:239) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:1099) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.call(JdbcTemplate.java:1135) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.core.simple.AbstractJdbcCall.executeCallInternal(AbstractJdbcCall.java:405) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.core.simple.AbstractJdbcCall.doExecute(AbstractJdbcCall.java:365) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:198) [spring-jdbc.jar:4.3.9.RELEASE] at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:135) [dal.jar:] at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:130) [dal.jar:] at org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeModification(SimpleJdbcCallsHandler.java:76) [dal.jar:] at org.ovirt.engine.core.dao.network.DnsResolverConfigurationDaoImpl.saveNameServersByDnsResolverConfigurationId(DnsResolverConfigurationDaoImpl.java:66) [dal.jar:] at org.ovirt.engine.core.dao.network.DnsResolverConfigurationDaoImpl.update(DnsResolverConfigurationDaoImpl.java:110) [dal.jar:] at org.ovirt.engine.core.dao.network.DnsResolverConfigurationDaoImpl.update(DnsResolverConfigurationDaoImpl.java:15) [dal.jar:] at org.ovirt.engine.core.dao.VdsDynamicDaoImpl.updateDnsResolverConfiguration(VdsDynamicDaoImpl.java:156) [dal.jar:] at org.ovirt.engine.core.dao.VdsDynamicDaoImpl.update(VdsDynamicDaoImpl.java:145) [dal.jar:] at org.ovirt.engine.core.dao.VdsDynamicDaoImpl.updateIfNeeded(VdsDynamicDaoImpl.java:343) [dal.jar:] at org.ovirt.engine.core.dao.VdsDynamicDaoImpl.updateIfNeeded(VdsDynamicDaoImpl.java:35) [dal.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.updateDynamicData(VdsManager.java:473) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.updatePendingData(VdsManager.java:511) [vdsbroker.jar:] at org.ovirt.engine.core.bll.scheduling.pending.PendingResourceManager.notifyHostManagers(PendingResourceManager.java:227) [bll.jar:] at org.ovirt.engine.core.bll.scheduling.SchedulingManager.schedule(SchedulingManager.java:361) [bll.jar:] at org.ovirt.engine.core.bll.RunVmCommand.getVdsToRunOn(RunVmCommand.java:853) [bll.jar:] at org.ovirt.engine.core.bll.RunVmCommand.runVm(RunVmCommand.java:256) [bll.jar:] at org.ovirt.engine.core.bll.RunVmCommand.perform(RunVmCommand.java:430) [bll.jar:] at org.ovirt.engine.core.bll.RunVmCommand.executeVmCommand(RunVmCommand.java:355) [bll.jar:] at org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:161) [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:1285) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1934) [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:1345) [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:468) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:450) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:403) [bll.jar:] at sun.reflect.GeneratedMethodAccessor134.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) at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:92) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.interceptorChainCompleted(WeldInvocationContext.java:98) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:117) [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.GeneratedMethodAccessor69.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.WeldInvocationContext.invokeNext(WeldInvocationContext.java:83) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.WeldInvocationContext.proceed(WeldInvocationContext.java:115) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.InterceptorImpl.intercept(InterceptorImpl.java:108) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:82) [wildfly-weld-ejb-11.0.0.Final.jar:11.0.0.Final] at org.jboss.as.weld.interceptors.EjbComponentInterceptorSupport.delegateInterception(EjbComponentInterceptorSupport.java:60) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:76) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:88) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor66.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.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:264) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:379) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:244) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-11.0.0.Final.jar:11.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view2.runAction(Unknown Source) [common.jar:] at org.ovirt.engine.api.restapi.resource.BackendResource.doAction(BackendResource.java:250) at org.ovirt.engine.api.restapi.resource.AbstractBackendActionableResource.doAction(AbstractBackendActionableResource.java:84) at org.ovirt.engine.api.restapi.resource.AbstractBackendActionableResource.doAction(AbstractBackendActionableResource.java:125) at org.ovirt.engine.api.restapi.resource.BackendVmResource.start(BackendVmResource.java:450) at org.ovirt.engine.api.v3.V3Server.adaptAction(V3Server.java:217) at org.ovirt.engine.api.v3.servers.V3VmServer.start(V3VmServer.java:216) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_161] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar: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.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:221) at io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:147) at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:111) at org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:180) at org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:98) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:117) at org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:72) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:78) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:42) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SsoRestApiNegotiationFilter.doFilter(SsoRestApiNegotiationFilter.java:84) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter.doFilter(SsoRestApiAuthFilter.java:47) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:59) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.aaa.filters.RestApiSessionValidationFilter.doFilter(RestApiSessionValidationFilter.java:35) [aaa.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.api.restapi.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:111) at org.ovirt.engine.api.restapi.security.CSRFProtectionFilter.doFilter(CSRFProtectionFilter.java:102) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.utils.servlet.CORSSupportFilter.doFilter(CORSSupportFilter.java:284) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_161] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_161]Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "name_server_pkey" Detail: Key (dns_resolver_configuration_id, address)=(8a941b6a-83aa-44de-9800-2a1ea6e8e029, 192.168.200.1) already exists. Where: SQL statement "INSERT INTO name_server( address, position, dns_resolver_configuration_id) VALUES ( v_address, v_position, v_dns_resolver_configuration_id)"PL/pgSQL function insertnameserver(uuid,character varying,smallint) line 3 at SQL statement at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:417) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:410) at org.jboss.jca.adapters.jdbc.CachedPreparedStatement.execute(CachedPreparedStatement.java:303) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.execute(WrappedPreparedStatement.java:442) at org.springframework.jdbc.core.JdbcTemplate$6.doInCallableStatement(JdbcTemplate.java:1138) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.core.JdbcTemplate$6.doInCallableStatement(JdbcTemplate.java:1135) [spring-jdbc.jar:4.3.9.RELEASE] at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:1083) [spring-jdbc.jar:4.3.9.RELEASE] ... 215 more2018-03-07 17:03:38,453-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Executing batch for procedure Updatevds_interface_statistics2018-03-07 17:03:38,453-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Mapped params: [v_iface_status, v_sample_time, v_rx_offset, v_rx_rate, v_tx_rate, v_tx_drop, v_tx_offset, v_id, v_rx_drop, v_rx_total, v_tx_total, v_vds_id]2018-03-07 17:03:38,453-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Mapped params: [v_iface_status, v_sample_time, v_rx_offset, v_rx_rate, v_tx_rate, v_tx_drop, v_tx_offset, v_id, v_rx_drop, v_rx_total, v_tx_total, v_vds_id]2018-03-07 17:03:38,453-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Mapped params: [v_iface_status, v_sample_time, v_rx_offset, v_rx_rate, v_tx_rate, v_tx_drop, v_tx_offset, v_id, v_rx_drop, v_rx_total, v_tx_total, v_vds_id]2018-03-07 17:03:38,453-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Mapped params: [v_iface_status, v_sample_time, v_rx_offset, v_rx_rate, v_tx_rate, v_tx_drop, v_tx_offset, v_id, v_rx_drop, v_rx_total, v_tx_total, v_vds_id]2018-03-07 17:03:38,453-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Mapped params: [v_iface_status, v_sample_time, v_rx_offset, v_rx_rate, v_tx_rate, v_tx_drop, v_tx_offset, v_id, v_rx_drop, v_rx_total, v_tx_total, v_vds_id]2018-03-07 17:03:38,456-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Executed batch2018-03-07 17:03:38,457-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Executing batch for procedure UpdateNumaNodeStatistics2018-03-07 17:03:38,457-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Mapped params: [v_numa_node_id, v_mem_free, v_usage_mem_percent, v_cpu_sys, v_cpu_user, v_cpu_idle, v_usage_cpu_percent]2018-03-07 17:03:38,459-05 DEBUG [org.ovirt.engine.core.dal.dbbroker.BatchProcedureExecutionConnectionCallback] (EE-ManagedThreadFactory-engineScheduled-Thread-82) [] Executed batch2018-03-07 17:03:38,462-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] EVENT_ID: USER_FAILED_RUN_VM(54), Failed to run VM backup_vm (User: admin@in:2018-03-07 17:03:38,466-05 DEBUG [org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil] (EE-ManagedThreadFactory-engine-Thread-182) [] Executing task: EE-ManagedThreadFactory-engine-Thread-1822018-03-07 17:03:38,467-05 INFO [org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] Lock freed to object 'EngineLock:{exclusiveLocks='[634c6a46-d057-4509-be3b-710716cbd56d=VM]', sharedLocks=''}'2018-03-07 17:03:38,467-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-21) [a514da44-d44f-46b9-8bdf-08ba2d513929] method: runAction, params: [RunVmOnce, RunVmOnceParams:{commandId='d5358409-e005-4c8b-a702-d4fa394ee9d2', user='null', commandType='Unknown', vmId='634c6a46-d057-4509-be3b-710716cbd56d'}], timeElapsed: 201ms2018-03-07 17:03:38,473-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-21) [] Operation Failed: [Internal Engine Error]</error>*

3 2

[OST][HC] Failed to deploy HE
by Sahina Bose 08 Mar '18

08 Mar '18

Error is - The host has been set in non_operational status, please check engine logs, fix accordingly and re-deploy. However there are no engine logs available. Is this error seen in HE suite as well? On Thu, Mar 8, 2018 at 8:58 AM, <jenkins(a)jenkins.phx.ovirt.org> wrote: > Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic- > suite-master/ > Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic- > suite-master/213/ > Build Number: 213 > Build Status: Failure > Triggered By: Started by timer > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #213 > [Sandro Bonazzola] image-ng-suite-4.2: sync 001_initialize_engine > > [Barak Korren] Enable mock to use bootstrap chroot for FC27/RAW > > [Sandro Bonazzola] gerrit-admin: move to el7 > > [Daniel Belenky] Add symlinks resolving capabilities to usrc > > [Barak Korren] Fix auto-merge in downstream instances > > [Dafna Ron] sync_mirror: removing fc24 > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran.

2 1

[ACTION REQUIRED] fixing CI on FC27 and RAWHIDE
by Barak Korren 08 Mar '18

08 Mar '18

Hi to all maintainers, TL;DR: If you use yum-utils on fedora (For e.g using yum-builddep) you need to switch to dnf-utils. As you may know we had encountered many issues when trying to get CI to work well for FC27 and Fedora RAWHIDE. One of the main reasons for the issues we've seen was that we were using 'yum' instead of 'dnf' to setup Fedora build and test environments. In FC27 and RAWHIDe, some packages simply stopped being compatible with yum. It took us a while to resolve this since we needed to get some patches merged upstream to the tools we use, but since yesterday we switched to using DNF for setting up FC environments. While we were waiting for the tools to get patched, our work-around was to freeze the mirrors our CI system uses so that newer and incompatible packages were invisible in CI. Since we now have a fix in place we started re-syncing our mirrors to get newer packages. A side effect of this, is that dnf-incompatible code in build and test scripts was exposed. One such common case is scripts using 'yum-builddep' with 'yum-utils' installed instead of 'dnf-utils'. In this case yum-incompatible packages will fail to be downloaded. Bottom line - if you use yum-based tools in your build/test scripts, they need to be changed to dnf-based tools when those scripts run in Fedora. Sometime this can be as simple as changing the packages listed in your *.packages files for Fedora. See for example this patch which switches from yum-utils to dnf-utils: https://gerrit.ovirt.org/c/88630/ -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

1 0

Re: [ovirt-devel] [ovirt-users] Unremovable disks created through the API
by Arik Hadas 07 Mar '18

07 Mar '18

On Tue, Mar 6, 2018 at 11:19 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote: > On Tue, Mar 06, 2018 at 11:14:40PM +0200, Arik Hadas wrote: > > On Tue, Mar 6, 2018 at 9:18 PM, Richard W.M. Jones <rjones(a)redhat.com> > > wrote: > > > > > > > > I've been playing with disk uploads through the API. As a result > > > I now have lots of disks in the states "Paused by System" and > > > "Paused by User". They are not attached to any VM, and I'm logged > > > in as admin@internal, but there seems to be no way to use them. > > > Even worse I've now run out of space so can't do anything else. > > > > > > How can I remove them? > > > > > > > Screenshot: http://oirase.annexia.org/tmp/ovirt.png > > > > > > Hi Richard, > > > > Selecting Upload->Cancel at that tab will remove such a disk. > > Note that it may take a minute or two. > > Yes, that works, thanks. > (Moving to devel-list) BTW, I think that the import process should include a preliminary phase where ovirt-engine is informed that the import process starts. Currently, IIUC, the new process is designed to be: 1. virt-v2v uploads the disks 2. virt-v2v calls an API with the OVF configuration so ovirt-engine will add the VM and attach the uploaded disks to that VM IMHO, the process should be comprised of: 1. virt-v2v calls an API with the (probably partial since the OS and other things are unknown at that point) OVF configuration 2. virt-v2v uploads the disks 3. virt-v2v provides the up-to-date configuration Step #1 will enable ovirt-engine: 1. Most importantly, to cleanup uploaded disks in case of an error during the import process. Otherwise, we require the client to clean them up, which can be challenging (e.g., if the virt-v2v process crashes). 2. To inform the user that the process has started - so he won't get surprised by seeing disks being uploaded suddenly. That will give a context to these upload operations. 3. To inform the user about the progress of the import process, much like we do today when importing VMs from vSphere to RHV. 4. To perform validations on the (partial) VM configuration, e.g., verifying that no VM with the same name exists/verifying there is enough space (optionally mapping different disks to different storage devices) and so on, before uploading the disks. The gaps I see: 1. We don't have a command for step #1 yet but that's something we can provide relatively quickly. We need it also to support uploading an OVA via oVirt's webadmin. 2. We have a command for step #3, but it is not exposed via the API. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~ > rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > Fedora Windows cross-compiler. Compile Windows programs, test, and > build Windows installers. Over 100 libraries supported. > http://fedoraproject.org/wiki/MinGW >

4 11

planned Jenkins restart
by Evgheni Dereveanchin 07 Mar '18

07 Mar '18

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new jobs will be scheduled during this maintenance period. I will inform you once it is over. Regards, Evgheni Dereveanchin

1 1

Fwd: Still Failing: oVirt/ovirt-engine#4888 (master - 1cc377f)
by Sandro Bonazzola 06 Mar '18

06 Mar '18

Hi, not sure who's monitoring Travis failures and maintaining Travis jobs, but looks like we have an error in the test suite It's currently failing on: ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.ovirt.engine.core.dal.job.ExecutionMessageDirectorTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.234 sec Running org.ovirt.engine.core.dal.dbbroker.DbConnectionUtilTest Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.936 sec <<< FAILURE! org.ovirt.engine.core.dal.dbbroker.DbConnectionUtilTest Time elapsed: 936 sec <<< FAILURE! java.lang.AssertionError: Unable to init tests Looks pretty much similar to what happens in jenkins for fcraw builds, tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1550033 ---------- Forwarded message ---------- From: Travis CI <builds(a)travis-ci.org> Date: 2018-03-06 7:53 GMT+01:00 Subject: Still Failing: oVirt/ovirt-engine#4888 (master - 1cc377f) To: sbonazzo(a)redhat.com *oVirt / ovirt-engine <https://travis-ci.org/oVirt/ovirt-engine?utm_source=email&utm_medium=notifi…>* (master <https://github.com/oVirt/ovirt-engine/tree/master>) Build #4888 is still failing. <https://travis-ci.org/oVirt/ovirt-engine/builds/349675802?utm_source=email&…> 4 minutes and 38 seconds *Yedidyah Bar David* 1cc377f <https://github.com/oVirt/ovirt-engine/commit/1cc377fa30286733aeb68aa75a5bc8…> Changeset → <https://github.com/oVirt/ovirt-engine/compare/6c9465241694...1cc377fa3028> packaging: setup: postgres95: Refuse to upgrade if new data dir is not empty Change-Id: I9f69ceb2b8ea773d1bb883c3e81734a3c4c8af3c Bug-Url: https://bugzilla.redhat.com/1546771 Signed-off-by: Yedidyah Bar David <didi(a)redhat.com> *Want to know about upcoming build environment updates?* Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! Sign up here <http://eepurl.com/9OCsP>. Documentation <https://docs.travis-ci.com> about Travis CI Need help? Mail support <support(a)travis-ci.com>! Choose who receives these build notification emails in your configuration file <https://docs.travis-ci.com/user/notifications>. *Would you like to test your private code?* Travis CI for Private Projects <https://travis-ci.com?utm_source=build_email_footer&utm_campaign=travis-ci.…> could be your new best friend! -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 4

Packages not landed on tested repo
by Sandro Bonazzola 06 Mar '18

06 Mar '18

Hi, looks like we have some packages which never passed OST, never landed in ovirt-4.2-snapshot repo and are currently causing failure building the appliance from 4.2 snapshot repo: 03:17:20,893 INFO program:Error: Package: ovirt-engine-4.2.2.3-0.0.master.20180305171049.git0e81394.el7.centos.noarch (ovirt-4.2-snapshot) 03:17:20,893 INFO program:Requires: ovirt-ansible-roles >= 1.1.2 03:17:20,894 INFO program:Error: Package: ovirt-engine-4.2.2.3-0.0.master.20180305171049.git0e81394.el7.centos.noarch (ovirt-4.2-snapshot) 03:17:20,896 INFO program:Requires: ovirt-js-dependencies 03:17:20,897 INFO program:Error: Package: ovirt-engine-4.2.2.3-0.0.master.20180305171049.git0e81394.el7.centos.noarch (ovirt-4.2-snapshot) 03:17:20,897 INFO program:Requires: ovirt-engine-wildfly-overlay >= 11.0.1 03:17:20,899 INFO program:Error: Package: ovirt-engine-api-explorer-0.0.3-0.alpha.1.20180215git9b54c9c.el7.centos.noarch (ovirt-4.2-snapshot) 03:17:20,900 INFO program:Requires: ovirt-js-dependencies >= 1.2 I'm now trying to get the missing packages pass thorough the whole testing pipeline but be aware those packages have already been released 3 months ago so they are stable and manually tested and were passing master OST. I've no clue on why they are missing in the 4.2 testing pipeline. -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

hosted-engine ovirt-system-tests
by Yedidyah Bar David 05 Mar '18

05 Mar '18

Hi all, Recently I have been pushing various patches to OST in order to verify specific bugs/fixes I was working on, using them with the "manual" jenkins job but with no immediate intention to get them merged. Main reason is that it's not clear what's the best approach to get such tests merged. Do we want a new suite? How often does it run? How long does it take? Do we have enough resources? etc. Do we have plans re this? Bugs/tickets/etc.? Do we want to do something? Specifically, do we want (eventually) many more suites? This seems unmanageable. A few suites, perhaps (also) using lago snapshots? Didn't try that myself, might be useful and relevant. Some examples: https://gerrit.ovirt.org/79203 https://gerrit.ovirt.org/79215 https://gerrit.ovirt.org/84813 https://gerrit.ovirt.org/88201 https://gerrit.ovirt.org/88234 And current one - this and the next ones in the stack: https://gerrit.ovirt.org/88331 Best regards, -- Didi

3 3

[ OST Failure Report ] [ oVirt 4.2 (ovirt-engine) ] [ 05-03-2018 ] [ 006_migrations.migrate_vm ]
by Dafna Ron 05 Mar '18

05 Mar '18

Hi, We have a failure in OST on test 006_migrations.migrate_vm. >From what I can see, the migration succeeded but because there was a KeyError: 'cpuUsage' engine assume the v is down and tries to retry migration. the re-try fails with vm already exists. *Link and headline of suspected patches: *Failed change: *https://gerrit.ovirt.org/#/c/88432/2 <https://gerrit.ovirt.org/#/c/88432/2> - * *engine : Events coming too soon on refresh caps* *CQ reported this as root ca*use but I don't think its related as well: *https://gerrit.ovirt.org/#/c/88404/ <https://gerrit.ovirt.org/#/c/88404/> - * *core: Auto SD selection on template version update* *Link to Job:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1021/ <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1021/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1021/artifa… <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1021/artifact/>(Relevant) error snippet from the log: <error>* *migration starts and finishs *but fails on vm state on eyError: 'cpuUsage' *2018-03-05 05:21:33,269-0500 INFO (jsonrpc/3) [api.virt] START migrate(params={u'incomingLimit': 2, u'tunneled': u'false', u'dstqemu': u'192.0.3.2', u'autoConverge': u'false', u'src': u'lago-basic-suite-4-2-host-0', u'enableGuestEvents': False, u'dst': u'lago-basic-suite-4-2-host-1:54321', u'vmId': u'a80596a2-f57b-4878-adc3-772363e42783', u'abortOnError': u'true', u'outgoingLimit': 2, u'compressed': u'false', u'method': u'online'}) from=::ffff:192.168.200.2,42452, flow_id=123f5fd3-81a4-4ba9-9034-525674696629, vmId=a80596a2-f57b-4878-adc3-772363e42783 (api:46)2018-03-05 05:21:33,271-0500 INFO (jsonrpc/3) [api.virt] FINISH migrate return={'status': {'message': 'Migration in progress', 'code': 0}, 'progress': 0} from=::ffff:192.168.200.2,42452, flow_id=123f5fd3-81a4-4ba9-9034-525674696629, vmId=a80596a2-f57b-4878-adc3-772363e42783 (api:52)2018-03-05 05:21:33,271-0500 INFO (jsonrpc/3) [jsonrpc.JsonRpcServer] RPC call VM.migrate succeeded in 0.00 seconds (__init__:573)2018-03-05 05:21:33,473-0500 INFO (monitor/bd2f874) [IOProcessClient] Closing client ioprocess-0 (__init__:583)2018-03-05 05:21:34,936-0500 INFO (migsrc/a80596a2) [virt.vm] (vmId='a80596a2-f57b-4878-adc3-772363e42783') Creation of destination VM took: 1 seconds (migration:473)2018-03-05 05:21:34,936-0500 INFO (migsrc/a80596a2) [virt.vm] (vmId='a80596a2-f57b-4878-adc3-772363e42783') starting migration to qemu+tls://lago-basic-suite-4-2-host-1/system with miguri tcp://192.0.3.2 <http://192.0.3.2> (migration:502)2018-03-05 05:21:36,356-0500 INFO (jsonrpc/7) [api.host] START getAllVmStats() from=::ffff:192.168.200.2,42452 (api:46)2018-03-05 05:21:36,359-0500 INFO (jsonrpc/7) [api.host] FINISH getAllVmStats return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} from=::ffff:192.168.200.2,42452 (api:52)2018-03-05 05:21:36,361-0500 INFO (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC call Host.getAllVmStats succeeded in 0.00 seconds (__init__:573)2018-03-05 05:21:38,861-0500 INFO (libvirt/events) [virt.vm] (vmId='a80596a2-f57b-4878-adc3-772363e42783') CPU stopped: onSuspend (vm:6063)2018-03-05 05:21:40,109-0500 WARN (periodic/0) [virt.periodic.VmDispatcher] could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['a80596a2-f57b-4878-adc3-772363e42783'] (periodic:323)2018-03-05 05:21:40,109-0500 INFO (migsrc/a80596a2) [virt.vm] (vmId='a80596a2-f57b-4878-adc3-772363e42783') migration took 6 seconds to complete (migration:514)2018-03-05 05:21:40,110-0500 INFO (migsrc/a80596a2) [virt.vm] (vmId='a80596a2-f57b-4878-adc3-772363e42783') Changed state to Down: Migration succeeded (code=4) (vm:1677)2018-03-05 05:21:40,116-0500 INFO (migsrc/a80596a2) [virt.vm] (vmId='a80596a2-f57b-4878-adc3-772363e42783') Stopping connection (guestagent:438)2018-03-05 05:21:41,118-0500 WARN (periodic/3) [virt.periodic.VmDispatcher] could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['a80596a2-f57b-4878-adc3-772363e42783'] (periodic:323)2018-03-05 05:21:42,063-0500 WARN (periodic/2) [virt.vmstats] Missing stat: 'balloon.current' for vm a80596a2-f57b-4878-adc3-772363e42783 (vmstats:552)2018-03-05 05:21:42,064-0500 ERROR (periodic/2) [virt.vmstats] VM metrics collection failed (vmstats:264)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vmstats.py", line 197, in send_metrics data[prefix + '.cpu.usage'] = stat['cpuUsage']KeyError: 'cpuUsage'* *</error>*

1 0

otopi on PPC (Was: [ACTION REQUIRED] upgrade to Fedora 27 for otopi on master)
by Yedidyah Bar David 04 Mar '18

04 Mar '18

(Changed subject) On Fri, Mar 2, 2018 at 1:17 AM, Eli Mesika <emesika(a)redhat.com> wrote: > I have upgraded to fc27 > I am not able to add a host to a PPC cluster : "no otopi module ..." Where do you get this error? > > otopi is installed On the engine? Host? Both? Generally it's enough to have it on the engine. > > rpm -qa |grep otopi > otopi-java-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch > otopi-common-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch > python2-otopi-devtools-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch > python2-otopi-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch > > Any ideas ? I have no experience with PPC, sorry. But in theory it should work the same, so let's try to debug "as usual". Thanks and best regards, > > > On Wed, Feb 28, 2018 at 7:01 PM, Greg Sheremeta <gshereme(a)redhat.com> wrote: >> >> [changing subject] >> >> Looks like we all have to upgrade Fedora devel machines to Fedora 27. >> >> Greg >> >> On Wed, Feb 28, 2018 at 11:05 AM, Yedidyah Bar David <didi(a)redhat.com> >> wrote: >>> >>> (Adding devel, was asked twice already) >>> >>> On Wed, Feb 28, 2018 at 4:52 PM, Eli Mesika <emesika(a)redhat.com> wrote: >>> > Hi Didi >>> > >>> > I am getting : >>> > >>> > >>> > ***L:ERROR Internal error: type object 'Stages' has no attribute >>> > 'ANSWER_FILE_GENERATED' >>> > 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 153, in >>> > execute >>> > sys.exc_info()[2], >>> > File "/usr/lib/python2.7/site-packages/otopi/util.py", line 81, in >>> > raiseExceptionInformation >>> > exec('raise info[1], None, info[2]') >>> > File "/usr/lib/python2.7/site-packages/otopi/main.py", line 147, in >>> > execute >>> > self.context.loadPlugins() >>> > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 859, >>> > in >>> > loadPlugins >>> > self._loadPluginGroups(plugindir, needgroups, loadedgroups) >>> > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 113, >>> > in >>> > _loadPluginGroups >>> > self._loadPlugins(path, path, groupname) >>> > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, in >>> > _loadPlugins >>> > self._loadPlugins(base, d, groupname) >>> > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, in >>> > _loadPlugins >>> > self._loadPlugins(base, d, groupname) >>> > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 101, >>> > in >>> > _loadPlugins >>> > os.path.basename(path), >>> > File "/usr/lib/python2.7/site-packages/otopi/util.py", line 105, in >>> > loadModule >>> > mod_desc >>> > File >>> > >>> > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/__init__.py", >>> > line 24, in <module> >>> > from . import answerfile >>> > File >>> > >>> > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/answerfile.py", >>> > line 38, in <module> >>> > class Plugin(plugin.PluginBase): >>> > File >>> > >>> > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/answerfile.py", >>> > line 60, in Plugin >>> > otopicons.Stages.ANSWER_FILE_GENERATED, >>> > PluginLoadException: type object 'Stages' has no attribute >>> > 'ANSWER_FILE_GENERATED' >>> > >>> >>> Please update otopi. >>> >>> If you are on fedora, you'll need to upgrade to fc27 first. >>> >>> Good luck, >>> -- >>> Didi >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >> >> > -- Didi

1 0

OST Failure - Weekly update [24/02/2018-02/03/2018]
by Dafna Ron 02 Mar '18

02 Mar '18

Hello, I would like to update on this week's failures and OST current status. We had a failed change that caused other changes to fail: 1. Remove use of end_play and fail module - https://gerrit.ovirt.org/#/c/88250/ date: 27-02-2018 version: master/4.2 test failed: 002_bootstrap.verify_add_hosts fix: reverted until it can be fixed: https://gerrit.ovirt.org/#/c/88327/ bug: https://bugzilla.redhat.com/show_bug.cgi?id=1540260 I re-triggered some of the failed changes that were effected by the above change. However, I am still seeing ovirt-engine project is failing in cq so I am expecting some new issues to appear which would be reported next week. *Below you can see the chart for this week's resolved issues but cause of failure: * Code= regression of working components/functionalities Configurations - package related issues Other = failed build artifacts Infra = infrastructure/OST/Lago related issues <https://gerrit.ovirt.org/#/c/88327/> <https://gerrit.ovirt.org/#/c/88327/> <https://gerrit.ovirt.org/#/c/88327/> *Below is a chart of resolved failures based on ovirt version* *Below is a chart showing failures by suite type: * Thank you, Dafna <https://gerrit.ovirt.org/#/c/88327/>

1 0

FC27 updates broken for ovirt-4.2
by Viktor Mihajlovski 02 Mar '18

02 Mar '18

I just tried to update the ovirt packages on my FC27 host, but failed due to https://gerrit.ovirt.org/#/c/87628/ vdsm now requires libvirt >= 3.10.0-132 but Fedora 27 has only 3.7.0-4 the moment. It's generic Fedora 27, but since I run on s390, cross-posting to s390 list. I guess there's good reason to require libvirt 3.10. Is there any chance that we can get libvirt updated for Fedora 27? -- Regards, Viktor Mihajlovski

5 14

[ACTION REQUIRED] upgrade to Fedora 27 for otopi on master
by Greg Sheremeta 02 Mar '18

02 Mar '18

[changing subject] Looks like we all have to upgrade Fedora devel machines to Fedora 27. Greg On Wed, Feb 28, 2018 at 11:05 AM, Yedidyah Bar David <didi(a)redhat.com> wrote: > (Adding devel, was asked twice already) > > On Wed, Feb 28, 2018 at 4:52 PM, Eli Mesika <emesika(a)redhat.com> wrote: > > Hi Didi > > > > I am getting : > > > > > > ***L:ERROR Internal error: type object 'Stages' has no attribute > > 'ANSWER_FILE_GENERATED' > > 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 153, in > > execute > > sys.exc_info()[2], > > File "/usr/lib/python2.7/site-packages/otopi/util.py", line 81, in > > raiseExceptionInformation > > exec('raise info[1], None, info[2]') > > File "/usr/lib/python2.7/site-packages/otopi/main.py", line 147, in > > execute > > self.context.loadPlugins() > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 859, in > > loadPlugins > > self._loadPluginGroups(plugindir, needgroups, loadedgroups) > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 113, in > > _loadPluginGroups > > self._loadPlugins(path, path, groupname) > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, in > > _loadPlugins > > self._loadPlugins(base, d, groupname) > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, in > > _loadPlugins > > self._loadPlugins(base, d, groupname) > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 101, in > > _loadPlugins > > os.path.basename(path), > > File "/usr/lib/python2.7/site-packages/otopi/util.py", line 105, in > > loadModule > > mod_desc > > File > > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/ > setup/bin/../plugins/ovirt-engine-common/base/core/__init__.py", > > line 24, in <module> > > from . import answerfile > > File > > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/ > setup/bin/../plugins/ovirt-engine-common/base/core/answerfile.py", > > line 38, in <module> > > class Plugin(plugin.PluginBase): > > File > > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/ > setup/bin/../plugins/ovirt-engine-common/base/core/answerfile.py", > > line 60, in Plugin > > otopicons.Stages.ANSWER_FILE_GENERATED, > > PluginLoadException: type object 'Stages' has no attribute > > 'ANSWER_FILE_GENERATED' > > > > Please update otopi. > > If you are on fedora, you'll need to upgrade to fc27 first. > > Good luck, > -- > Didi > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >

2 1

ERROR Internal error: type object 'Stages' has no attribute 'ANSWER_FILE_GENERATED'
by Eitan Raviv 01 Mar '18

01 Mar '18

Hi, I am getting the above error on the latest master tip when running engine set-up. Anybody can advise? Thanks -- Eitan Raviv IRC: erav (#ovirt #vdsm #devel #rhev-dev)

4 5

Inventory Analyzer
by Jason Bryant 01 Mar '18

01 Mar '18

Hello, I have attempted a few times to upload a log-collector which has a confirmed DB in it but I continually get the following error: An internal error occurred: ('analyzer failed, rc=%s, err=%r', 255, 'Unable to detect the database dump from sosreport, aborting..\n') See logs for full stacktrace. Thank you, Jason

2 2

Re: [ovirt-devel] [rhev-devel] Fwd: [ACTION REQUIRED] upgrade to Fedora 27 for otopi on master
by Yedidyah Bar David 01 Mar '18

01 Mar '18

(Re-adding devel) On Thu, Mar 1, 2018 at 4:52 AM, Greg Sheremeta <gshereme(a)redhat.com> wrote: > Setup worked for me immediately after upgrade. I'll forward you my repos in > a separate email. > > This was an interesting sequence: > > greg@dauntless:/etc/yum.repos.d % sudo dnf update otopi -y > Failed to synchronize cache for repo 'region51-chrome-gnome-shell', > disabling. > Failed to synchronize cache for repo 'rcm-tools-fedora-rpms', disabling. > Last metadata expiration check: 0:29:21 ago on Wed 28 Feb 2018 09:16:13 PM > EST. > Package otopi available, but not installed. > No match for argument: otopi > Error: No packages marked for upgrade. > greg@dauntless:/etc/yum.repos.d % sudo dnf install otopi -y > Failed to synchronize cache for repo 'region51-chrome-gnome-shell', > disabling. > Failed to synchronize cache for repo 'rcm-tools-fedora-rpms', disabling. > Last metadata expiration check: 0:29:36 ago on Wed 28 Feb 2018 09:16:13 PM > EST. > Package python2-otopi-1.8.0-0.0.master.20180228112959.git6eccc31.fc27.noarch > is already installed, skipping. > Dependencies resolved. > Nothing to do. > Complete! Adding Yuval for review. Yuval recently re-introduced python3 support to otopi, and following the fedora python packaging guidelines. Yuval, reading the guidelines again, it seems like it's valid to keep the package name 'otopi' and make it Provide: python2-otopi, instead of the opposite. WDYT? > > > > On Wed, Feb 28, 2018 at 5:20 PM, Alexander Wels <awels(a)redhat.com> wrote: >> >> On Wednesday, February 28, 2018 12:02:11 PM EST Greg Sheremeta wrote: >> >> > ---------- Forwarded message ---------- >> >> > From: Greg Sheremeta <gshereme(a)redhat.com> >> >> > Date: Wed, Feb 28, 2018 at 12:01 PM >> >> > Subject: [ACTION REQUIRED] upgrade to Fedora 27 for otopi on master >> >> > To: Yedidyah Bar David <didi(a)redhat.com> >> >> > Cc: Eli Mesika <emesika(a)redhat.com>, devel <devel(a)ovirt.org> >> >> > >> >> > >> >> > [changing subject] >> >> > >> >> > Looks like we all have to upgrade Fedora devel machines to Fedora 27. >> >> > >> >> > Greg >> >> > >> >> >> >> I upgraded to F27 and now I am getting something about: >> >> >> >> [awels@awels ovirt-engine]$ ./bin/engine-setup >> ***L:ERROR Internal error: No module named ovirt_setup_lib >> >> I tried removing ovirt-engine, and re-installing it, and dnf is telling >> me: >> >> >> >> Error: >> Problem: conflicting requests >> - nothing provides rubygem-fluent-plugin-rewrite-tag-filter needed by >> ovirt-engine-4.3.0-0.0.master.20180225182524.git8b8f3a52a6.fc27.noarch >> - nothing provides rubygem-fluent-plugin-rewrite-tag-filter needed by >> ovirt-engine-4.3.0-0.0.master.20180226201906.git5831910bef.fc27.noarch >> - nothing provides rubygem-fluent-plugin-rewrite-tag-filter needed by >> ovirt-engine-4.3.0-0.0.master.20180227170348.git8b617da448.fc27.noarch >> >> What am I missing repo wise? >> >> >> >> > On Wed, Feb 28, 2018 at 11:05 AM, Yedidyah Bar David <didi(a)redhat.com> >> >> > >> >> > wrote: >> >> > > (Adding devel, was asked twice already) >> >> > > >> >> > > On Wed, Feb 28, 2018 at 4:52 PM, Eli Mesika <emesika(a)redhat.com> >> > > wrote: >> >> > > > Hi Didi >> >> > > > >> >> > > > I am getting : >> >> > > > >> >> > > > >> >> > > > ***L:ERROR Internal error: type object 'Stages' has no attribute >> >> > > > 'ANSWER_FILE_GENERATED' >> >> > > > >> >> > > > 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 153, in >> >> > > > >> >> > > > execute >> >> > > > >> >> > > > sys.exc_info()[2], >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/util.py", line 81, in >> >> > > > >> >> > > > raiseExceptionInformation >> >> > > > >> >> > > > exec('raise info[1], None, info[2]') >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/main.py", line 147, in >> >> > > > >> >> > > > execute >> >> > > > >> >> > > > self.context.loadPlugins() >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 859, >> > > > in >> >> > > > >> >> > > > loadPlugins >> >> > > > >> >> > > > self._loadPluginGroups(plugindir, needgroups, loadedgroups) >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 113, >> > > > in >> >> > > > >> >> > > > _loadPluginGroups >> >> > > > >> >> > > > self._loadPlugins(path, path, groupname) >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, >> > > > in >> >> > > > >> >> > > > _loadPlugins >> >> > > > >> >> > > > self._loadPlugins(base, d, groupname) >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 70, >> > > > in >> >> > > > >> >> > > > _loadPlugins >> >> > > > >> >> > > > self._loadPlugins(base, d, groupname) >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 101, >> > > > in >> >> > > > >> >> > > > _loadPlugins >> >> > > > >> >> > > > os.path.basename(path), >> >> > > > >> >> > > > File "/usr/lib/python2.7/site-packages/otopi/util.py", line 105, in >> >> > > > >> >> > > > loadModule >> >> > > > >> >> > > > mod_desc >> >> > > > >> >> > > > File >> >> > > > >> >> > > > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup >> >> > > >> >> > > /bin/../plugins/ovirt-engine-common/base/core/__init__.py", >> >> > > >> >> > > > line 24, in <module> >> >> > > > >> >> > > > from . import answerfile >> >> > > > >> >> > > > File >> >> > > > >> >> > > > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup >> >> > > >> >> > > /bin/../plugins/ovirt-engine-common/base/core/answerfile.py", >> >> > > >> >> > > > line 38, in <module> >> >> > > > >> >> > > > class Plugin(plugin.PluginBase): >> >> > > > File >> >> > > > >> >> > > > "/home/emesika/ovirt-engine-1481197/share/ovirt-engine/setup >> >> > > >> >> > > /bin/../plugins/ovirt-engine-common/base/core/answerfile.py", >> >> > > >> >> > > > line 60, in Plugin >> >> > > > >> >> > > > otopicons.Stages.ANSWER_FILE_GENERATED, >> >> > > > >> >> > > > PluginLoadException: type object 'Stages' has no attribute >> >> > > > 'ANSWER_FILE_GENERATED' >> >> > > >> >> > > Please update otopi. >> >> > > >> >> > > If you are on fedora, you'll need to upgrade to fc27 first. >> >> > > >> >> > > Good luck, >> >> > > -- >> >> > > Didi >> >> > > _______________________________________________ >> >> > > Devel mailing list >> >> > > Devel(a)ovirt.org >> >> > > http://lists.ovirt.org/mailman/listinfo/devel >> >> >> >> > > -- Didi

1 0

[ OST Failure Report ] [ oVirt 4.2/Master (ovirt-engine-metrics) ] [ 28-02-2018 ] [ 002_bootstrap.verify_add_hosts]
by Dafna Ron 01 Mar '18

01 Mar '18

Hi, We have a failure in test 002_bootstrap.verify_add_hosts. the issue seems to be a miss-configured role in ansible *Link and headline of suspected patches: * *Remove use of end_play and fail module - https://gerrit.ovirt.org/#/c/88250/ <https://gerrit.ovirt.org/#/c/88250/>Link to Job:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/950/ <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/950/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/950/artifac… <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/950/artifacts>(Relevant) error snippet from the log: <error>* 2018-02-28 05:01:29,984 p=17139 u=ovirt | TASK [oVirt.ovirt-include-vars-files : Include oVirt metrics config.yml.d vars directory] *** 2018-02-28 05:01:30,007 p=17139 u=ovirt | ok: [lago-basic-suite-4-2-host-0 -> localhost] => { "ansible_facts": {}, "ansible_included_var_files": [], "changed": false } 2018-02-28 05:01:30,016 p=17139 u=ovirt | TASK [oVirt.ovirt-initial-validations/validate-config-yml : If output plugin is elasticsearch, validate host address is set] *** 2018-02-28 05:01:30,047 p=17139 u=ovirt | changed: [lago-basic-suite-4-2-host-0 -> localhost] => {} MSG: ERROR oVirt Metrics store is not configured. This host will not be configured to send metrics 2018-02-28 05:01:30,056 p=17139 u=ovirt | TASK [oVirt.ovirt-initial-validations/validate-config-yml : If output plugin is fluentd, validate host address is set] *** 2018-02-28 05:01:30,073 p=17139 u=ovirt | skipping: [lago-basic-suite-4-2-host-0] => { "changed": false, "skip_reason": "Conditional result was False" } 2018-02-28 05:01:30,082 p=17139 u=ovirt | TASK [oVirt.ovirt-initial-validations/validate-config-yml : Validate viaq_metrics_store parameter is set] *** 2018-02-28 05:01:30,111 p=17139 u=ovirt | changed: [lago-basic-suite-4-2-host-0 -> localhost] => {} MSG: ERROR viaq_metrics_store parameter is mandatory. Please set the parameter to 'true' or 'false'. 2018-02-28 05:01:30,119 p=17139 u=ovirt | TASK [oVirt.ovirt-initial-validations/validate-config-yml : Validate viaq_metrics_store parameter] *** 2018-02-28 05:01:30,137 p=17139 u=ovirt | skipping: [lago-basic-suite-4-2-host-0] => { "changed": false, "skip_reason": "Conditional result was False" } 2018-02-28 05:01:30,146 p=17139 u=ovirt | TASK [oVirt.ovirt-initial-validations/validate-config-yml : Validate openshift_deployment_type parameter is set] *** 2018-02-28 05:01:30,168 p=17139 u=ovirt | fatal: [lago-basic-suite-4-2-host-0]: FAILED! => {} MSG: The conditional check 'viaq_metrics_store == true' failed. The error was: error while evaluating conditional (viaq_metrics_store == true): 'viaq_metrics_store' is undefined The error appears to have been in '/usr/share/ansible/roles/oVirt.metrics/roles/oVirt.ovirt-initial-validations/validate-config-yml/tasks/main.yml': line 48, column 3, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - name: "Validate openshift_deployment_type parameter is set" ^ here *</error>* *Thanks, Dafna*

1 1