January 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) 27 Apr '18

27 Apr '18

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

2 4

[vdsm][RFC] reconsidering branching out ovirt-4.2
by Francesco Romani 06 Feb '18

06 Feb '18

Hi all, It is time again to reconsider branching out the 4.2 stable branch. So far we decided to *not* branch out, and we are taking tags for ovirt 4.2 releases from master branch. This means we are merging safe and/or stabilization patches only in master. I think it is time to reconsider this decision and branch out for 4.2, because of two reasons: 1. it sends a clearer signal that 4.2 is going in stabilization mode 2. we have requests from virt team, which wants to start working on the next cycle features. If we decide to branch out, I'd start the new branch on monday, February 5 (1 week from now). The discussion is open, please share your acks/nacks for branching out, and for the branching date. I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll execute the above plan. -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

5 5

[ACTION-REQUIRED] Making accurate CI for oVirt 4.2
by Barak Korren 06 Feb '18

06 Feb '18

Hi, This message is aimed for project maintainers. Other developers may also find it interesting to have a glimpse at the oVirt-wide test and composition processes. TL;DR: To get accurate CI for oVirt 4.2, most projects need to add 4.2 jobs in YAML. Before I can explain what the current issue is and which action is required, I'm need to provide a brief overview into how oVirt CI works. oVirt CI has two major components to it: 1. The STDCI component which is used to build and test individual projects. Most developers interact with this on a daily basis as it is responding on GitHub and Gerrit events. 2. The "change-queue" (CQ) component which is used to automatically compose the whole of oVirt from its sub projects and run system tests (OST) on it. This component is used to gather the information that is used by the infra team to compose the "OST failure report" you can occasionally see being sent to this list. The change queue is also used to automatically maintain the 'tested' and '*-snapshot' (AKA nightly) repositories. The way the CQ composes oVirt is by looking at the post-merge STDCI 'build-artifacts' jobs, and collecting together artifacts built by jobs that target a specific oVirt version into that version's change queue. Essentially the '*_master_build-artifacts-*' jobs go into the 'ovirt-master' change queue, the '*_4.1_build-artifacts-*' jobs go into the 'ovirt-4.1' change queue etc. Over the course of the oVirt 4.2 development, most project used their 'master' branch, which is typically mapped to '*_master_*' jobs, for developing 4.2 code. So the 'ovirt-master' CQ provided good indication of the state of 4.2 code. As projects started addeing 4.2 branches, we have created an 'ovirt-4.2' CQ to gather them. We did so under the assumption that most projects will branch soon after. The assumption turned up to be wrong as most projects did not yet fork and may not do so in the near future. As some projects did fork, the end result is that currently: ___there is no accurate representation of oVirt 4.2 in CI___ 'ovirt-master' CQ no longer represents oVirt 4.2 as some projects already have some 4.3 code in their 'master' branches. 'ovirt-4.2' CQ does not represent oVirt 4.2 as most projects do not push artifacts into it. To get any benefit from CI, we need to have it represent what we are going to release. This means that at this point we need all projects to have '*_4.2_build-artifacts-*' jobs that map to the code that is intended to be included in oVirt 4.2. Projects can either: 1. Create 4.2 branches and map the new jobs to them. 2. Keep 4.2 development in 'master' and create '4.2' jobs that map to it. Taking route #2 means a commitment to not adding any 4.3 code to the 'master' branch. Please keep it, as rolling back "too new" builds from the various repos and caches we have is very difficult. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

7 15

[IOPROCESS] New release for Fedora
by Nir Soffer 04 Feb '18

04 Feb '18

Hi all, I released ioprocess 1.0.0 for Fedora 27 and 28. If you are using Fedora, please install the new version from the updates-testing and test it. Please share your feedback here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbe8141dd2 This version will be available soon from oVirt repositories. Thanks, Nir

1 1

Re: [ovirt-devel] [RFC] reconsidering branching out ovirt-4.2
by Tal Nisan 31 Jan '18

31 Jan '18

For alignment purposes between the projects we should consider branch ovirt-engine as well. At this point in time I'm for it, would like to hear any acks/nacks so we can decide how we proceeed On Mon, Jan 29, 2018 at 9:02 AM, Dan Kenigsberg <danken(a)redhat.com> wrote: > On Mon, Jan 29, 2018 at 9:39 AM, Francesco Romani <fromani(a)redhat.com> > wrote: > > Hi all, > > > > > > It is time again to reconsider branching out the 4.2 stable branch. > > > > So far we decided to *not* branch out, and we are taking tags for ovirt > > 4.2 releases from master branch. > > > > This means we are merging safe and/or stabilization patches only in > master. > > > > > > I think it is time to reconsider this decision and branch out for 4.2, > > because of two reasons: > > > > 1. it sends a clearer signal that 4.2 is going in stabilization mode > > > > 2. we have requests from virt team, which wants to start working on the > > next cycle features. > > > > > > If we decide to branch out, I'd start the new branch on monday, February > > 5 (1 week from now). > > > > > > The discussion is open, please share your acks/nacks for branching out, > > and for the branching date. > > > > > > I for myself I'm inclined to branch out, so if noone chimes in (!!) I'll > > execute the above plan. > > For network we don't see a lot of pending 4.2 work - except for the > requirement to support el7.5. On the other hand, we too have already a > patch for 4.3. Thus I'm fine with branching next week. > > When you do branch, please make sure to follow Barak Korren's request on > the > [ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2 > thread. > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >

6 6

Fix for: "The CPU type of the cluster is unknown"
by Arik Hadas 30 Jan '18

30 Jan '18

Hi all, Last week we merged a patch that may reset the cluster's CPU and therefore could cause the following error to happen when trying to run a VM: "The CPU type of the cluster is unknown. ..." A fix is now posted. In the meantime, this can be resolved by refreshing the capabilities of one of your hosts. Arik

1 0

What does SDM.merge's param "base_generation" in subchain_info means?
by pengyixiang 29 Jan '18

29 Jan '18

------=_Part_140011_191578780.1517228861952 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGVsbG8sIGV2ZXJ5b25lIQogICAgIFdoZW4gd2UgY2FsbCAiU0RNLm1lcmdlIiwgd2UgbmVlZCBh IHBhcmFtICJiYXNlX2dlbmVyYXRpb24iIGluIFsxXSwgYW5kIEkga25vdyBbMl0gd2lsbCBiZSBj YWxsZWQgYW5kICJiYXNlX2dlbmVyYXRpb24iIGlzIHRyYW5zbGF0ZWQgdG8gInJlcXVlc3RlZF9n ZW4iLCB0aGF0IG1lYW5zICJHRU4iIGluIGRpc2sgbWV0YWRhdGE/CklmIHNvLCBob3cgZGlkIHRo aXMgIkdFTiIgd29ya2VkIGFuZCBzZXRlZD8gSSBzZWUgbWFueSAqLm1ldGEgaXMgIkdFTj0wIiwg YW5kIHNvbWUgaXMgIkdFTj0xIiBpbiBbM10uIAoKCgoKSG9wZSB0byBnZXQgeW91ciByZXBseSwg VGhhbmsgeW91IQoKCgoKWzFdICB7J3N1YmNoYWluX2luZm8nOiB7J2ltZ19pZCc6ICc5MTgzNzUy NS04NTBkLTRlNzQtOWE3ZS1jODliNzkzZDBlNWInLCAnc2RfaWQnOiAnOTNiOGEyYzktZjUyNy00 ZWIzLWFjZmItYWY3NmFiMjRmYmJlJywgJ3RvcF9pZCc6ICc0ZTUxZDRlNS05NjMwLTQ1YTYtOTgy OS0wMTI0NjBlN2Q2N2EnLCAnYmFzZV9pZCc6ICdmZGY0NzU4NC0yMWFhLTQ1YjItOTkyNS0xNTdm ZjU0ZjVlN2UnLCAnYmFzZV9nZW5lcmF0aW9uJzogMH0sICdqb2JfaWQnOiAnNzY2YTMwNTAtNDc2 Yy00OGFlLTk0NzAtM2JlYzc4NjdhNmNkJ30KCgpbMl0gIGh0dHBzOi8vZ2l0aHViLmNvbS9vVmly dC92ZHNtL2Jsb2IvMDdkMDUyODdhYzE0OTZhZDQ5OTE1ZTAyNmQzNGUyOWNhNGRhNjM1Yi9saWIv dmRzbS9zdG9yYWdlL3ZvbHVtZS5weSNMNjAyCgoKWzNdIApET01BSU49OTNiOGEyYzktZjUyNy00 ZWIzLWFjZmItYWY3NmFiMjRmYmJlIENUSU1FPTE1MTYwOTA0NTQgRk9STUFUPUNPVyBESVNLVFlQ RT0yIExFR0FMSVRZPUxFR0FMIFNJWkU9MTY3NzcyMTYwIFZPTFRZUEU9SU5URVJOQUwgREVTQ1JJ UFRJT049IElNQUdFPWY4ODJlN2NjLWY1N2UtNDhmZi05Yjg3LWJiYTM1MzMxZTk4MyBQVVVJRD05 MDUwZjk1Ni02ODM2LTRmY2UtOGQyNy02OWRmMTNjNGY4NWMgTVRJTUU9MCBQT09MX1VVSUQ9IFRZ UEU9U1BBUlNFIEdFTj0xIEVPRg== ------=_Part_140011_191578780.1517228861952 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+aGVsbG8sIGV2ZXJ5b25lITwvZGl2PjxkaXY+Jm5ic3A7 ICZuYnNwOyAmbmJzcDtXaGVuIHdlIGNhbGwgIlNETS5tZXJnZSIsIHdlIG5lZWQgYSBwYXJhbSZu YnNwOyJiYXNlX2dlbmVyYXRpb24iIGluIFsxXSwgYW5kIEkga25vdyBbMl0gd2lsbCBiZSBjYWxs ZWQgYW5kICJiYXNlX2dlbmVyYXRpb24iIGlzIHRyYW5zbGF0ZWQgdG8gIjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTEsIDIyMSk7IGNvbG9yOiByZ2IoMzYsIDQxLCA0 Nik7IGZvbnQtZmFtaWx5OiBTRk1vbm8tUmVndWxhciwgQ29uc29sYXMsICZxdW90O0xpYmVyYXRp b24gTW9ubyZxdW90OywgTWVubG8sIENvdXJpZXIsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4 OyB3aGl0ZS1zcGFjZTogcHJlOyI+cmVxdWVzdGVkX2dlbjwvc3Bhbj4iLCB0aGF0IG1lYW5zICJH RU4iIGluIGRpc2sgbWV0YWRhdGE/PC9kaXY+PGRpdj5JZiBzbywgaG93IGRpZCB0aGlzICJHRU4i IHdvcmtlZCBhbmQgc2V0ZWQ/IEkgc2VlIG1hbnkgKi5tZXRhIGlzICI8c3BhbiBzdHlsZT0iY29s b3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9udC1mYW1pbHk6IFNGTW9uby1SZWd1bGFyLCBDb25zb2xh cywgJnF1b3Q7TGliZXJhdGlvbiBNb25vJnF1b3Q7LCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNl OyBmb250LXNpemU6IDEycHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPkdFTj0wPC9zcGFuPiIs IGFuZCBzb21lIGlzICI8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9udC1m YW1pbHk6IFNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywgJnF1b3Q7TGliZXJhdGlvbiBNb25vJnF1 b3Q7LCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsiPkdFTj0xPC9zcGFuPiIgaW4gWzNdLiZuYnNwOzwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUx LCA1MSk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxMy45MXB4OyI+SG9wZSB0byBn ZXQgeW91ciByZXBseSwgVGhhbmsgeW91ITwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlsxXSZuYnNwOyZuYnNwO3snc3ViY2hhaW5faW5mbyc6IHsnaW1nX2lk JzogJzkxODM3NTI1LTg1MGQtNGU3NC05YTdlLWM4OWI3OTNkMGU1YicsICdzZF9pZCc6ICc5M2I4 YTJjOS1mNTI3LTRlYjMtYWNmYi1hZjc2YWIyNGZiYmUnLCAndG9wX2lkJzogJzRlNTFkNGU1LTk2 MzAtNDVhNi05ODI5LTAxMjQ2MGU3ZDY3YScsICdiYXNlX2lkJzogJ2ZkZjQ3NTg0LTIxYWEtNDVi Mi05OTI1LTE1N2ZmNTRmNWU3ZScsICc8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigyNTUsIDAsIDAp OyI+YmFzZV9nZW5lcmF0aW9uPC9zcGFuPic6IDB9LCAnam9iX2lkJzogJzc2NmEzMDUwLTQ3NmMt NDhhZS05NDcwLTNiZWM3ODY3YTZjZCd9PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5bMl0mbmJz cDsmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzNiwgNDEsIDQ2KTsgZm9udC1mYW1pbHk6 IFNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywgJnF1b3Q7TGliZXJhdGlvbiBNb25vJnF1b3Q7LCBN ZW5sbywgQ291cmllciwgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IHdoaXRlLXNwYWNlOiBw cmUtd3JhcDsiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9vVmlydC92ZHNtL2Jsb2IvMDdk MDUyODdhYzE0OTZhZDQ5OTE1ZTAyNmQzNGUyOWNhNGRhNjM1Yi9saWIvdmRzbS9zdG9yYWdlL3Zv bHVtZS5weSNMNjAyIiBfc3JjPSJodHRwczovL2dpdGh1Yi5jb20vb1ZpcnQvdmRzbS9ibG9iLzA3 ZDA1Mjg3YWMxNDk2YWQ0OTkxNWUwMjZkMzRlMjljYTRkYTYzNWIvbGliL3Zkc20vc3RvcmFnZS92 b2x1bWUucHkjTDYwMiI+aHR0cHM6Ly9naXRodWIuY29tL29WaXJ0L3Zkc20vYmxvYi8wN2QwNTI4 N2FjMTQ5NmFkNDk5MTVlMDI2ZDM0ZTI5Y2E0ZGE2MzViL2xpYi92ZHNtL3N0b3JhZ2Uvdm9sdW1l LnB5I0w2MDI8L2E+PC9zcGFuPjwvZGl2PjxkaXY+PGZvbnQgY29sb3I9IiMyNDI5MmUiIGZhY2U9 IlNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywgTGliZXJhdGlvbiBNb25vLCBNZW5sbywgQ291cmll ciwgbW9ub3NwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7Ij48YnI+PC9zcGFuPjwvZm9udD48L2Rpdj48ZGl2PlszXSZuYnNwOzwvZGl2Pjxk aXY+PGZvbnQgY29sb3I9IiMyNDI5MmUiIGZhY2U9IlNGTW9uby1SZWd1bGFyLCBDb25zb2xhcywg TGliZXJhdGlvbiBNb25vLCBNZW5sbywgQ291cmllciwgbW9ub3NwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMnB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij5ET01BSU49OTNiOGEyYzkt ZjUyNy00ZWIzLWFjZmItYWY3NmFiMjRmYmJlCkNUSU1FPTE1MTYwOTA0NTQKRk9STUFUPUNPVwpE SVNLVFlQRT0yCkxFR0FMSVRZPUxFR0FMClNJWkU9MTY3NzcyMTYwClZPTFRZUEU9SU5URVJOQUwK REVTQ1JJUFRJT049CklNQUdFPWY4ODJlN2NjLWY1N2UtNDhmZi05Yjg3LWJiYTM1MzMxZTk4MwpQ VVVJRD05MDUwZjk1Ni02ODM2LTRmY2UtOGQyNy02OWRmMTNjNGY4NWMKTVRJTUU9MApQT09MX1VV SUQ9ClRZUEU9U1BBUlNFCkdFTj0xCkVPRjwvc3Bhbj48L2ZvbnQ+PC9kaXY+PC9kaXY+PGJyPjxi cj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_140011_191578780.1517228861952--

1 0

PHX planned maintenance 29.01.2018 @19:00 GMT
by Evgheni Dereveanchin 29 Jan '18

29 Jan '18

Hi everyone, Planned works are going to be performed in the PHX data center today. They are related to core networking hardware upgrades and may cause short connectivity loss to services hosted by the oVirt project, including: * Jenkins CI * Package repositories * project website * mailing lists The maintenance window starts at 19:00 GMT and has a duration of one hour. I will pause CI job execution before the maintenance window so builds will be queued and executed after network upgrades are implemented to decrease the possibility of false positives. I will follow up with any further updates. -- Regards, Evgheni Dereveanchin

1 1

Error while setting up disk in ovirt-engine.
by Avinash Dasoundhi 29 Jan '18

29 Jan '18

Hello Everyone I have set up ovirt-engine for testing purpose and, I am using ovirt-vdsmfake[1] to provision host and vms on that ovirt-engine. But I am facing an error while creating a disk. I have provision 10 hosts, all are up with their own local storage. And when I am trying to add a disk to the disk section, error popups like "*Error while executing action Add Disk to VM: General Exception*". I saw the logs, thought of some permission error, checked that but still this error is coming. Can somebody provide some details on it? I am attaching the engine.log with this mail. Thank You -- AVINASH DASOUNDHI ASSOCIATE SOFTWARE ENGINEER IN ENG PERF R&D, RHCSA Red Hat BLR <https://www.redhat.com/> IRC - tenstormavi adasound(a)redhat.com M: +91-8653245552 <https://red.ht/sig>

3 2

Re: [ovirt-devel] [CQ]: 86865, 8 (otopi) failed "ovirt-master" system tests, but isn't the failure root cause
by Yedidyah Bar David 29 Jan '18

29 Jan '18

On Mon, Jan 29, 2018 at 1:47 PM, oVirt Jenkins <jenkins(a)ovirt.org> wrote: > A system test invoked by the "ovirt-master" change queue including change > 86865,8 (otopi) failed. However, this change seems not to be the root cause for > this failure. Change 86679,4 (otopi) that this change depends on or is based > on, was detected as the cause of the testing failures. > > This change had been removed from the testing queue. Artifacts built from this > change will not be released until either change 86679,4 (otopi) is fixed and > this change is updated to refer to or rebased on the fixed version, or this > change is modified to no longer depend on it. > > For further details about the change see: > https://gerrit.ovirt.org/#/c/86865/8 > > For further details about the change that seems to be the root cause behind the > testing failures see: > https://gerrit.ovirt.org/#/c/86679/4 That's indeed the reason for the failure. This patch adds to otopi a check for before=/after= parameters for event methods. It causes CI to fail due to bad ones in engine-setup, should be fixed by: https://gerrit.ovirt.org/86858 > > For failed test results see: > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5149/ > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra -- Didi

1 0

what does the vm.merge do in vdsm?
by Pen 29 Jan '18

29 Jan '18

This is a multi-part message in MIME format. ------=_NextPart_5A69FAF8_0A3DD098_26818FA0 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 aGkNCiAgICAgIHdoYXQgbWVhbnMgaW4gdmRzbSBhcGkgbWVyZ2UncyBwYXJhbSAiZHJpdmUu dm9sdW1lSUQiIGluIFsxXaO/SWYgSSB3YW50IGRlbGV0ZSAic25hcHNob3QxIiBpbiBzbmFw c2hvdCBjaGFpbiBbM10sIA0KImRyaXZlLnZvbHVtZUlEIiBtZWFucyAic25hcHNob3QyIiBv ciAgImFjdGl2ZV9pbWciPyBJIGhhdmUgc2VlbiBhYm91dCBkb2N1bWVudCBpbiBbMl0sIHRo ZW4gSSBoYXZlIGEgcXVlc3Rpb24sIA0KSWYgd2Ugd2FudCBkZWxldGUgInNuYXBzaG90MSIg aW4gWzRdLCBhbmQgInNuYXBzaG90MSIgaXMgInNuYXBzaG90MiIncyBzcmNWb2x1bWUgYW5k ICJzbmFwc2hvdDMiJ3Mgc3JjVm9sdW1lIGF0IHRoZSANCnNhbWUgdGltZSwgd2hhdCBzaG91 bGQgSSBkbz8gbWVyZ2UgdHdpY2U/DQoNCg0KDQoNClsxXSANCkBhcGkubWV0aG9kDQpkZWYg bWVyZ2Uoc2VsZiwgZHJpdmUsIGJhc2VWb2xVVUlELCB0b3BWb2xVVUlELCBiYW5kd2lkdGg9 MCwgam9iVVVJRD1Ob25lKToNCiAgICByZXR1cm4gc2VsZi52bS5tZXJnZSgNCiAgICAgICAg ZHJpdmUsIGJhc2VWb2xVVUlELCB0b3BWb2xVVUlELCBiYW5kd2lkdGgsIGpvYlVVSUQpDQoN Cg0KWzJdIGh0dHBzOi8vd3d3Lm92aXJ0Lm9yZy9kZXZlbG9wL3JlbGVhc2UtbWFuYWdlbWVu dC9mZWF0dXJlcy9zdG9yYWdlL2xpdmUtbWVyZ2UvDQoNClszXSANCmJhY2tpbmdfaW1nIC0t LSBzbmFwc2hvdDEgLS0tIHNuYXBzaG90MiAtLS0gYWN0aXZlX2ltZw0KDQpbNF0NCmJhY2tp bmdfaW1nIC0tLSBzbmFwc2hvdDEgLS0tIHNuYXBzaG90MiAtLS0gYWN0aXZlX2ltZw0KICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgICAgLS0tLS0gc25hcHNob3Qz ------=_NextPart_5A69FAF8_0A3DD098_26818FA0 Content-Type: text/html; charset="gb18030" Content-Transfer-Encoding: base64 aGk8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoYXQgbWVhbnMgaW4gdmRz bSBhcGkgbWVyZ2UncyBwYXJhbSAiZHJpdmUudm9sdW1lSUQiIGluIFsxXaO/SWYgSSB3YW50 IGRlbGV0ZSAic25hcHNob3QxIiBpbiBzbmFwc2hvdCBjaGFpbiBbM10sIDxicj4iZHJpdmUu dm9sdW1lSUQiIG1lYW5zICJzbmFwc2hvdDIiIG9yJm5ic3A7ICJhY3RpdmVfaW1nIj8gSSBo YXZlIHNlZW4gYWJvdXQgZG9jdW1lbnQgaW4gWzJdLCB0aGVuIEkgaGF2ZSBhIHF1ZXN0aW9u LCA8YnI+SWYgd2Ugd2FudCBkZWxldGUgInNuYXBzaG90MSIgaW4gWzRdLCBhbmQgInNuYXBz aG90MSIgaXMgInNuYXBzaG90MiIncyBzcmNWb2x1bWUgYW5kICJzbmFwc2hvdDMiJ3Mgc3Jj Vm9sdW1lIGF0IHRoZSA8YnI+c2FtZSB0aW1lLCB3aGF0IHNob3VsZCBJIGRvPyBtZXJnZSB0 d2ljZT88YnI+PGJyPjxicj48YnI+PGJyPlsxXSA8YnI+PHByZSBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjojZmZmZmZmO2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6J0RlamFWdSBTYW5z IE1vbm8nO2ZvbnQtc2l6ZToxMS4zcHQ7Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBiMjsi PkBhcGkubWV0aG9kPGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDA4MDtmb250 LXdlaWdodDpib2xkOyI+ZGVmIDwvc3Bhbj5tZXJnZSg8c3BhbiBzdHlsZT0iY29sb3I6Izk0 NTU4ZDsiPnNlbGY8L3NwYW4+LCBkcml2ZSwgYmFzZVZvbFVVSUQsIHRvcFZvbFVVSUQsIGJh bmR3aWR0aD08c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBmZjsiPjA8L3NwYW4+LCBqb2JVVUlE PTxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMDgwOyI+Tm9uZTwvc3Bhbj4pOjxicj4gICAgPHNw YW4gc3R5bGU9ImNvbG9yOiMwMDAwODA7Zm9udC13ZWlnaHQ6Ym9sZDsiPnJldHVybiA8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NDU1OGQ7Ij5zZWxmPC9zcGFuPi52bS5tZXJnZSg8 YnI+ICAgICAgICBkcml2ZSwgYmFzZVZvbFVVSUQsIHRvcFZvbFVVSUQsIGJhbmR3aWR0aCwg am9iVVVJRCk8YnI+PGJyPjxicj5bMl0gaHR0cHM6Ly93d3cub3ZpcnQub3JnL2RldmVsb3Av cmVsZWFzZS1tYW5hZ2VtZW50L2ZlYXR1cmVzL3N0b3JhZ2UvbGl2ZS1tZXJnZS88YnI+PGJy PlszXSA8YnI+YmFja2luZ19pbWcgLS0tIHNuYXBzaG90MSAtLS0gc25hcHNob3QyIC0tLSBh Y3RpdmVfaW1nPGJyPjxicj5bNF08YnI+YmFja2luZ19pbWcgLS0tIHNuYXBzaG90MSAtLS0g c25hcHNob3QyIC0tLSBhY3RpdmVfaW1nPGJyPiAgICAgICAgICAgICAgICAgICAgIHw8YnI+ ICAgICAgICAgICAgICAgICAgICAgfDxicj4gICAgICAgICAgICAgICAgICAgICAtLS0tLSBz bmFwc2hvdDM8YnI+PC9wcmU+ ------=_NextPart_5A69FAF8_0A3DD098_26818FA0--

2 1

[ OST Failure Report ] [ oVirt Master (vcredist-x86) ] [ 26-01-2018 ] [ 002_bootstrap.verify_add_all_hosts ]
by Dafna Ron 26 Jan '18

26 Jan '18

Hi, We had a failure on test 002_bootstrap.verify_add_all_hosts in Ovirt Master I don't think the patch reported is related to the issue. >From what I can see, the host was locked when we tried to query its status and since we couldn't fence the host we exited in timeout. I do not think the reported patch was the reason for failure. *Link and headline of reported patches: https://gerrit.ovirt.org/#/c/82234/1 <https://gerrit.ovirt.org/#/c/82234/1> - Initial import from ovirt-wgt-toolchainLink to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5123/artifact/>(Relevant) error snippet from the log: <error>2018-01-26 06:37:31,022-05 INFO [org.ovirt.engine.core.bll.RefreshHostCapabilitiesCommand] (ForkJoinPool-1-worker-4) [75b3e642] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[52ee1a61-31c3-4af8-ae28-65f0953f1804=VDS, HOST_NETWORK52ee1a61-31c3-4af8-ae28-65f0953f1804=HOST_NETWORK]', sharedLocks=''}'2018-01-26 06:37:31,022-05 WARN [org.ovirt.engine.core.bll.RefreshHostCapabilitiesCommand] (ForkJoinPool-1-worker-4) [75b3e642] Validation of action 'RefreshHostCapabilities' failed for user SYSTEM. Reasons: VAR__ACTION__REFRESH,VAR__TYPE__HOST_CAPABILITIES,ACTION_TYPE_FAILED_OBJECT_LOCKED2018-01-26 06:37:31,373-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (SSL Stomp Reactor) [1d883766] MESSAGEcontent-length:80destination:jms.topic.vdsm_responsescontent-type:application/jsonsubscription:ce434ca4-0c91-44b6-843a-7f8cff40d8e4{"jsonrpc": "2.0", "id": "8f1c8652-044c-4051-85d7-3d290ee2014f", "result": true}^@2018-01-26 06:37:31,374-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker] (ResponseWorker) [] Message received: {"jsonrpc": "2.0", "id": "8f1c8652-044c-4051-85d7-3d290ee2014f", "result": true}2018-01-26 06:37:31,374-05 ERROR [org.ovirt.vdsm.jsonrpc.client.JsonRpcClient] (ResponseWorker) [] Not able to update response for "8f1c8652-044c-4051-85d7-3d290ee2014f"2018-01-26 06:37:31,376-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message] (SSL Stomp Reactor) [1d883766] MESSAGEcontent-length:802018-01-26 06:37:35,147-05 ERROR [org.ovirt.engine.core.bll.pm.FenceProxyLocator] (EE-ManagedThreadFactory-engineScheduled-Thread-8) [78ab5d20] Can not run fence action on host 'lago-basic-suite-master-host-0', no suitable proxy host was found.</error>*

1 0

How did vm.merge do when we delete a snapshot that pointed by several other's snapshot's srcVol (as several other snapshot's backing) ?
by pengyixiang 26 Jan '18

26 Jan '18

------=_Part_119726_124618439.1516957895504 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGVsbG8sIGV2ZXJ5b25lIQogICAgICBJIGhhdmUgc2VlbiBhYm91dCBkb2N1bWVudCBpbiBbMl0g YWJvdXQgdm0ubWVyZ2UgaW4gWzFdLCB0aGVuIEkgaGF2ZSBhIHF1ZXN0aW9uLCBJZiB3ZSB3YW50 IGRlbGV0ZSAic25hcHNob3QxIiBpbiBbM10sIGFuZCAic25hcHNob3QxIiBpcyAic25hcHNob3Qy IidzIHNyY1ZvbHVtZSBhbmQgInNuYXBzaG90MyIncyBzcmNWb2x1bWUgYXQgdGhlIAoKc2FtZSB0 aW1lLCB3aGF0IHNob3VsZCBJIGRvPyAgbGlidmlydCB3aWxsIG1lcmdlIHNuYXBzaG90MSB0byBz bmFwc2hvdDIgYW5kIHNuYXBzaG90Mz8gIG9yIG90aGVyIHdheXMgZGlkIGZvciBlZmZpY2llbmN5 PwoKCgoKVGhhbmtzIGZvciB5b3VyIGhlbHAgSWYgSSBjYW4gZ2V0IGEgcmVwbHkuCgoKCgoKWzFd IAoKQGFwaS5tZXRob2QKZGVmIG1lcmdlKHNlbGYsIGRyaXZlLCBiYXNlVm9sVVVJRCwgdG9wVm9s VVVJRCwgYmFuZHdpZHRoPTAsIGpvYlVVSUQ9Tm9uZSk6CnJldHVybiBzZWxmLnZtLm1lcmdlKAog ICAgICAgIGRyaXZlLCBiYXNlVm9sVVVJRCwgdG9wVm9sVVVJRCwgYmFuZHdpZHRoLCBqb2JVVUlE KQoKClsyXSBodHRwczovL3d3dy5vdmlydC5vcmcvZGV2ZWxvcC9yZWxlYXNlLW1hbmFnZW1lbnQv ZmVhdHVyZXMvc3RvcmFnZS9saXZlLW1lcmdlLwoKClszXQpiYWNraW5nX2ltZyAtLS0gc25hcHNo b3QxIC0tLSBzbmFwc2hvdDIgLS0tIGFjdGl2ZV9pbWcKICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgIC0tLS0tIHNuYXBzaG90 Mw== ------=_Part_119726_124618439.1516957895504 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7bHVjaWRh IEdyYW5kZSZxdW90OywgVmVyZGFuYSwgJnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7OyI+aGVs bG8sIGV2ZXJ5b25lITwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtsdWNpZGEg R3JhbmRlJnF1b3Q7LCBWZXJkYW5hLCAmcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDs7Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O2x1Y2lkYSBHcmFuZGUmcXVvdDssIFZlcmRhbmEs ICZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OzsiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7bHVjaWRhIEdyYW5kZSZxdW90 OywgVmVyZGFuYSwgJnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7OyI+SSBoYXZlIHNlZW4gYWJv dXQgZG9jdW1lbnQgaW4gWzJdIGFib3V0IHZtLm1lcmdlIGluIFsxXSwgdGhlbiBJIGhhdmUgYSBx dWVzdGlvbiwmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtsdWNp ZGEgR3JhbmRlJnF1b3Q7LCBWZXJkYW5hLCAmcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDs7Ij5J ZiB3ZSB3YW50IGRlbGV0ZSAic25hcHNob3QxIiBpbiBbM10sIGFuZCAic25hcHNob3QxIiBpcyAi c25hcHNob3QyIidzIHNyY1ZvbHVtZSBhbmQgInNuYXBzaG90MyIncyBzcmNWb2x1bWUgYXQgdGhl Jm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O2x1Y2lkYSBHcmFuZGUm cXVvdDssIFZlcmRhbmEsICZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OzsiPjxkaXY+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtsdWNpZGEgR3JhbmRlJnF1b3Q7LCBWZXJkYW5hLCAm cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDs7Ij5zYW1lIHRpbWUsIHdoYXQgc2hvdWxkIEkgZG8/ Jm5ic3A7IGxpYnZpcnQgd2lsbCBtZXJnZSBzbmFwc2hvdDEgdG8gc25hcHNob3QyIGFuZCBzbmFw c2hvdDM/Jm5ic3A7IG9yIG90aGVyIHdheXMgZGlkIGZvciBlPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTNw eDsiPmZmaWNpZW5jeT88L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 ICZxdW90O2x1Y2lkYSBHcmFuZGUmcXVvdDssIFZlcmRhbmEsICZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OzsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 ICZxdW90O2x1Y2lkYSBHcmFuZGUmcXVvdDssIFZlcmRhbmEsICZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OzsiPjxicj48L3NwYW4+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 ICZxdW90O2x1Y2lkYSBHcmFuZGUmcXVvdDssIFZlcmRhbmEsICZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OzsiPlRoYW5rcyBmb3IgeW91ciBoZWxwIElmIEkgY2FuIGdldCBhIHJlcGx5Ljwvc3Bh bj48L2Rpdj48ZGl2PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O2x1Y2lkYSBHcmFuZGUm cXVvdDssIFZlcmRhbmEsICZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OzsiPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O2x1Y2lkYSBHcmFuZGUmcXVv dDssIFZlcmRhbmEsICZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OzsiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogJnF1b3Q7bHVjaWRhIEdyYW5kZSZxdW90OywgVmVyZGFuYSwgJnF1b3Q7TWlj cm9zb2Z0IFlhSGVpJnF1b3Q7OyI+WzFdJm5ic3A7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1p bHk6ICZxdW90O2x1Y2lkYSBHcmFuZGUmcXVvdDssIFZlcmRhbmEsICZxdW90O01pY3Jvc29mdCBZ YUhlaSZxdW90OzsiPjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyNS42MTMzcHg7IGZvbnQtZmFt aWx5OiAmcXVvdDtEZWphVnUgU2FucyBNb25vJnF1b3Q7OyBmb250LXNpemU6IDExLjNwdDsiPjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDE3OCk7Ij5AYXBpLm1ldGhvZDxicj48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMTI4KTsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij5k ZWYgPC9zcGFuPm1lcmdlKDxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDE0OCwgODUsIDE0MSk7Ij5z ZWxmPC9zcGFuPiwgZHJpdmUsIGJhc2VWb2xVVUlELCB0b3BWb2xVVUlELCBiYW5kd2lkdGg9PHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMjU1KTsiPjA8L3NwYW4+LCBqb2JVVUlEPTxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDEyOCk7Ij5Ob25lPC9zcGFuPik6PGJyPiAgICA8c3Bh biBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAxMjgpOyBmb250LXdlaWdodDogYm9sZDsiPnJldHVy biA8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTQ4LCA4NSwgMTQxKTsiPnNlbGY8L3Nw YW4+LnZtLm1lcmdlKDxicj4gICAgICAgIGRyaXZlLCBiYXNlVm9sVVVJRCwgdG9wVm9sVVVJRCwg YmFuZHdpZHRoLCBqb2JVVUlEKTxicj48YnI+PGJyPlsyXSBodHRwczovL3d3dy5vdmlydC5vcmcv ZGV2ZWxvcC9yZWxlYXNlLW1hbmFnZW1lbnQvZmVhdHVyZXMvc3RvcmFnZS9saXZlLW1lcmdlLzxi cj48YnI+PGJyPlszXTxicj5iYWNraW5nX2ltZyAtLS0gc25hcHNob3QxIC0tLSBzbmFwc2hvdDIg LS0tIGFjdGl2ZV9pbWc8YnI+ICAgICAgICAgICAgICAgICAgICAgfDxicj4gICAgICAgICAgICAg ICAgICAgICB8PGJyPiAgICAgICAgICAgICAgICAgICAgIC0tLS0tIHNuYXBzaG90MzwvcHJlPjwv ZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxwPiZuYnNwOzwvcD48L3Nw YW4+ ------=_Part_119726_124618439.1516957895504--

2 1

Problem when loading images via web interface
by Dmitry Semenov 25 Jan '18

25 Jan '18

While loading disk image (via the web interface) in cluster01 on storage01, storage02 - everything is going well. While loading disk image (via the web interface) in cluster02 on storage03, storage04 - the problem occurs, the image isn't loaded, the process stops at the stage: paused by System (at the same time loading straightly through API goes without problems). screenshot: https://yadi.sk/i/9WtkDlT23Riqxp Logs are applied (engine.log): https://pastebin.com/54k5j7hC image size: ~1.3 GB my scheme: data_center_01 cluster01 host01 \ host02 - storage01, storage02 host03 / cluster02 host04 \ host05 - storage03, storage04 host06 / HostedEngine in cluster01 oVirt: Version 4.2.0.2-1.el7.centos -- Best regards,

4 5

[25-1-18] [ OST Failure Report] [oVirt Master (vdsm)] [post-002_bootstrap]
by Daniel Belenky 25 Jan '18

25 Jan '18

Hi, We failed to setup host in OST upgrade from 4.1 to master suite. Please note that the upgrade suite installs 4.1 engine, then upgrades it to master and then tries to set up a host. *Links:* 1. Link to failed job <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5093/artifact…> 2. Suspected patch: Gerrit 86474/33 <https://gerrit.ovirt.org/#/c/86474/33> *Error snippet from engine.log (engine):* 2018-01-24 15:13:20,257-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host lago-upgrade-from-release-suite-master-host0: Failed to execute stage 'Closing up': Failed to start service 'vdsmd'. 2018-01-24 15:13:20,301-05 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host lago-upgrade-from-release-suite-master-host0. Stage: Clean up. 2018-01-24 15:13:20,304-05 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host lago-upgrade-from-release-suite-master-host0. Stage: Pre-termination. 2018-01-24 15:13:20,332-05 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host lago-upgrade-from-release-suite-master-host0. Retrieving installation logs to: '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20180124151320-lago-upgrade-from-release-suite-master-host0-34609a2f.log'. 2018-01-24 15:13:29,227-05 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing Host lago-upgrade-from-release-suite-master-host0. Stage: Termination. 2018-01-24 15:13:29,321-05 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog] (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] SSH error running command root@lago-upgrade-from-release-suite-master-host0:'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALOG/customization=bool:True': IOException: Command returned failure code 1 during SSH session 'root@lago-upgrade-from-release-suite-master-host0' 2018-01-24 15:13:29,322-05 ERROR [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] Error during host lago-upgrade-from-release-suite-master-host0 install 2018-01-24 15:13:29,324-05 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] Host installation failed for host '4d681c3b-e8db-4a71-b5e3-0db096e3ae9c', 'lago-upgrade-from-release-suite-master-host0': Command returned failure code 1 during SSH session 'root@lago-upgrade-from-release-suite-master-host0' 2018-01-24 15:13:29,330-05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] START, SetVdsStatusVDSCommand(HostName = lago-upgrade-from-release-suite-master-host0, SetVdsStatusVDSCommandParameters:{hostId='4d681c3b-e8db-4a71-b5e3-0db096e3ae9c', status='InstallFailed', nonOperationalReason='NONE', stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 5e6c4a3e 2018-01-24 15:13:29,339-05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] FINISH, SetVdsStatusVDSCommand, log id: 5e6c4a3e 2018-01-24 15:13:29,346-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] EVENT_ID: VDS_INSTALL_FAILED(505), Host lago-upgrade-from-release-suite-master-host0 installation failed. Command returned failure code 1 during SSH session 'root@lago-upgrade-from-release-suite-master-host0'. *Error snippet from /var/log/messages (host0):* 15:13:19 host0 NetworkManager[580]: <info> (bondscan-Ncw7DP): new Bond device (carrier: OFF, driver: 'bonding', ifindex: 4) 15:13:19 host0 vdsm-tool: Traceback (most recent call last): 15:13:19 host0 vdsm-tool: File "/usr/bin/vdsm-tool", line 219, in main 15:13:19 host0 vdsm-tool: return tool_command[cmd]["command"](*args) 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/tool/network.py", line 97, in dump_bonding_options 15:13:19 host0 vdsm-tool: sysfs_options_mapper.dump_bonding_options() 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 48, in dump_bonding_options 15:13:19 host0 vdsm-tool: jdump(_get_default_bonding_options(), f) 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 60, in _get_default_bonding_options 15:13:19 host0 vdsm-tool: with _bond_device(bond_name): 15:13:19 host0 vdsm-tool: File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ 15:13:19 host0 vdsm-tool: return self.gen.next() 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 102, in _bond_device 15:13:19 host0 vdsm-tool: _unmanage_nm_device(bond_name) 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 116, in _unmanage_nm_device 15:13:19 host0 vdsm-tool: dev.managed = False 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/nm/networkmanager.py", line 90, in managed 15:13:19 host0 vdsm-tool: self._device.managed = value 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/nm/nmdbus/device.py", line 81, in managed 15:13:19 host0 vdsm-tool: return self._set_property('Managed', value) 15:13:19 host0 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/nm/nmdbus/device.py", line 88, in _set_property 15:13:19 host0 vdsm-tool: self.IF_NAME, property_name, property_value) 15:13:19 host0 vdsm-tool: File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 70, in __call__ 15:13:19 host0 vdsm-tool: return self._proxy_method(*args, **keywords) 15:13:19 host0 vdsm-tool: File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in __call__ 15:13:19 host0 vdsm-tool: **keywords) 15:13:19 host0 vdsm-tool: File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking 15:13:19 host0 vdsm-tool: message, timeout) 15:13:19 host0 vdsm-tool: DBusException: org.freedesktop.DBus.Error.AccessDenied: Property "Managed" of interface "org.freedesktop.NetworkManager.Device" is not settable Thanks, -- DANIEL BELENKY RHV DEVOPS

3 6

Lago oVirt plugin v0.44 Release Announcement
by Gal Ben Haim 24 Jan '18

24 Jan '18

Hi All, On behalf of the Lago team, I'm pleased to announce Lago oVirt plugin v0.44 is available! For a detailed release announcement, please refer to our Github page at: https://github.com/lago-project/lago-ost-plugin/releases/tag/0.44 As always, if you find any issues, or willing to contribute, visit our GitHub page. Enjoy! -- *GAL bEN HAIM* RHV DEVOPS

1 0

[ OST Failure Report ] [ oVirt Master (ovirt-engine-sdk) ] [24-01-2018 ] [ 007_sd_reattach.deactivate_storage_domain ]
by Dafna Ron 24 Jan '18

24 Jan '18

Hi, We failed 007_sd_reattach.deactivate_storage_domain once again for trying to de-activate a storage domain with running tasks. I did not find the bug I thought I opened on this issue in the past so I opened a new one. https://bugzilla.redhat.com/show_bug.cgi?id=1538228 *Link and headline of suspected patches: Patch is not related *to the issue. *Link to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5076/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5076/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5076/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5076/artifact/>(Relevant) error snippet from the log: <error>2018-01-24 09:12:01,070-05 WARN [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-30) [87107c27-275d-4fee-a456-013615e817cc] Validation of action 'DeactivateStorageDomainWithOvfUpdate' failed for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__DEACTIVATE,ERROR_CANNOT_DEACTIVATE_DOMAIN_WITH_TASKS2018-01-24 09:12:01,071-05 INFO [org.ovirt.engine.core.bll.storage.domain.DeactivateStorageDomainWithOvfUpdateCommand] (default task-30) [87107c27-275d-4fee-a456-013615e817cc] Lock freed to object 'EngineLock:{exclusiveLocks='[2b834f56-9469-4c01-98bf-531d41812fe4=STORAGE]', sharedLocks='[3e20e50b-4536-4f03-9bd3-7f02d321e734=POOL]'}'2018-01-24 09:12:01,075-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-30) [87107c27-275d-4fee-a456-013615e817cc] method: runAction, params: [DeactivateStorageDomainWithOvfUpdate, DeactivateStorageDomainWithOvfUpdateParameters:{commandId='df244508-5d1c-4485-82e6-11bc426072bc', user='null', commandType='Unknown'}], timeElapsed: 70ms2018-01-24 09:12:01,079-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-30) [] Operation Failed: [Cannot deactivate Storage while there are running tasks on this Storage.-Please wait until tasks will finish and try again.]</error>*

1 0

[ OST Failure Report ] [ oVirt Master (vdsm)] [ 24-01-2018 ] [ 002_bootstrap.add_hosts ]
by Dafna Ron 24 Jan '18

24 Jan '18

Hi, We have a failure in test 002_bootstrap.add_hosts on Ovirt-Master in project vdsm. The issue seems to be that we fail to configure vdsm correctly. *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/86474/ <https://gerrit.ovirt.org/#/c/86474/> - * *net: unmanage bonds used for options gatheringLink to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5067 <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5067>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5067/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5067/artifact/>(Relevant) error snippet from the log: <error>Running configure...Reconfiguration of abrt is done.Reconfiguration of passwd is done.WARNING: LVM local configuration: /etc/lvm/lvmlocal.conf is not based on vdsm configurationBacking up /etc/lvm/lvmlocal.conf to /etc/lvm/lvmlocal.conf.201801231944Installing /usr/share/vdsm/lvmlocal.conf at /etc/lvm/lvmlocal.confUnits need configuration: {'lvm2-lvmetad.service': {'LoadState': 'loaded', 'ActiveState': 'active'}, 'lvm2-lvmetad.socket': {'LoadState': 'loaded', 'ActiveState': 'active'}}Reconfiguration of lvm is done.Reconfiguration of sebool is done.Reconfiguration of libvirt is done.Reconfiguration of sanlock is done.2018-01-23 19:44:08,411-0500 DEBUG otopi.plugins.ovirt_host_deploy.vdsm.packages plugin.execute:926 execute-output: ('/usr/bin/vdsm-tool', 'configure', '--force') stderr:Traceback (most recent call last): File "/usr/bin/vdsm-tool", line 219, in main return tool_command[cmd]["command"](*args) File "/usr/lib/python2.7/site-packages/vdsm/tool/__init__.py", line 38, in wrapper func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line 141, in configure _configure(c) File "/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line 88, in _configure getattr(module, 'configure', lambda: None)() File "/usr/lib/python2.7/site-packages/vdsm/tool/configurators/bond_defaults.py", line 40, in configure sysfs_options_mapper.dump_bonding_options() File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 48, in dump_bonding_options jdump(_get_default_bonding_options(), f) File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 60, in _get_default_bonding_options with _bond_device(bond_name): File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 102, in _bond_device _unmanage_nm_device(bond_name) File "/usr/lib/python2.7/site-packages/vdsm/network/link/bond/sysfs_options_mapper.py", line 116, in _unmanage_nm_device dev.managed = False File "/usr/lib/python2.7/site-packages/vdsm/network/nm/networkmanager.py", line 90, in managed self._device.managed = value File "/usr/lib/python2.7/site-packages/vdsm/network/nm/nmdbus/device.py", line 81, in managed return self._set_property('Managed', value) File "/usr/lib/python2.7/site-packages/vdsm/network/nm/nmdbus/device.py", line 88, in _set_property self.IF_NAME, property_name, property_value) File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 70, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in __call__ **keywords) File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking message, timeout)DBusException: org.freedesktop.DBus.Error.AccessDenied: Property "Managed" of interface "org.freedesktop.NetworkManager.Device" is not settable2018-01-23 19:44:08,412-0500 WARNING otopi.plugins.ovirt_host_deploy.vdsm.packages packages._reconfigure:151 Cannot configure vdsm2018-01-23 19:44:08,413-0500 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND **%EventEnd STAGE closeup METHOD otopi.plugins.ovirt_host_deploy.vdsm.packages.Plugin._reconfigure (None)2018-01-23 19:44:08,414-0500 DEBUG otopi.context context._executeMethod:128 Stage closeup METHOD otopi.plugins.otopi.network.firewalld.Plugin._closeup2018-01-23 19:44:08,414-0500 DEBUG otopi.plugins.otopi.dialog.machine dialog.__logString:204 DIALOG:SEND **%EventStart STAGE closeup METHOD otopi.plugins.otopi.network.firewalld.Plugin._closeup (None):</error>*

1 0

unboundid-ldapsdk-4.0.4-1.fc27 is now available for testing
by Sandro Bonazzola 23 Jan '18

23 Jan '18

On Fedora 27 we had previously 4.0.1. The new releases 4.0.4 will be soon available in updates-testing repository and includes several bug fixes and a few enhancements. You can see release notes here: https://github.com/pingidentity/ldapsdk/releases In oVirt this package is required by ovirt-engine-extension-aaa-ldap. If you're going to test the package, please provide karma: https://bodhi.fedoraproject.org/updates/unboundid-ldapsdk-4.0.4-1.fc27 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>

1 0

[ OST Failure Report ] [ oVirt 4.1 ] [ 23-01-2018 ] [ 002_bootstrap.add_cluster ]
by Dafna Ron 23 Jan '18

23 Jan '18

Hi, We are failing test 002_bootstrap.add_cluster on 4.1 suite. this is an issue we encountered on 4.2 and we think is related to libvirt. *Link and headline of suspected patches: Patch is not related to the underline issue: * https://gerrit.ovirt.org/#/c/85609/7 - spec: update dependencies for CVE-2017-5754,CVE-2017-5753,CVE-2017-5715 *Link to Job:http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1527 <http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1527>Link to all logs:http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1527/artifa… <http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1527/artifact/>(Relevant) error snippet from the log: <error>* 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-4.1_change-queue-tester/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 211, in add_cluster add_cluster_4(prefix) File "/home/jenkins/workspace/ovirt-4.1_change-queue-tester/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 237, in add_cluster_4 cpu_family = prefix.virt_env.get_ovirt_cpu_family() File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 151, in get_ovirt_cpu_family ','.join(cpu_map[host.cpu_vendor].iterkeys()) RuntimeError: Unsupported CPU model: Haswell-noTSX-IBRS. Supported models: IvyBridge,Westmere,Skylake,Penryn,Haswell,Broadwell,Nehalem,Skylake-Client,Broadwell-noTSX,Conroe,SandyBridge,Haswell-noTSX *</error>*

1 0

[ OST Failure Report ] [ oVirt Master ] [ 23-06-2018 ] [ 001_initialize_engine.initialize_engine ]
by Dafna Ron 23 Jan '18

23 Jan '18

Hi, We are failing test "001_initialize_engine.initialize_engine" in basic suite. Can you please check this issue? *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/85809/ <https://gerrit.ovirt.org/#/c/85809/> - * *packaging: raise if network provider name is duplicatedLink to Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5047/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5047/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5047/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5047/artifact/>(Relevant) error snippet from the log: <error>[ INFO ] Stage: Setup validation[ ERROR ] Failed to execute stage 'Setup validation': could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432? could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432? [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180123025743-gngssk.log[ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20180123025751-setup.conf'[ INFO ] Stage: Pre-termination[ INFO ] Stage: Termination[ ERROR ] Execution of setup failed('FATAL Internal error (main): could not connect to server: Connection refused\n\tIs the server running on host "localhost" (::1) and accepting\n\tTCP/IP connections on port 5432?\ncould not connect to server: Connection refused\n\tIs the server running on host "localhost" (127.0.0.1) and accepting\n\tTCP/IP connections on port 5432?\n',)2018-01-23 07:57:51,174::ssh.py::ssh::96::lago.ssh::DEBUG::Command 178de848 on lago-basic-suite-master-engine errors: 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 157, in execute self.context.runSequence() File "/usr/lib/python2.7/site-packages/otopi/context.py", line 765, in runSequence util.raiseExceptionInformation(infos[0]) 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/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py", line 894, in _validate_provider_uniqueness existing_provider_id = self._check_provider_exists() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/network/ovirtproviderovn.py", line 138, in _check_provider_exists ownConnection=True, File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 238, in execute database=database, File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 172, in connect sslmode=sslmode, File "/usr/lib64/python2.7/site-packages/psycopg2/__init__.py", line 164, in connect conn = _connect(dsn, connection_factory=connection_factory, async=async)OperationalError: could not connect to server: Connection refused Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432?could not connect to server: Connection refused Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?</error>*

1 0

Browser Bookmarkable places
by Alexander Wels 22 Jan '18

22 Jan '18

Hi, I just merged [1] into master, this patch will allow you to use browser bookmarks to save your current location in the application and return to it later. Basically the current entity and place are synchronized into the URL bar of your browser, which together with some previous infra structure allows you to use your browsers bookmark to go directly to an entity from being logged out. The same is true for search queries on main views. Alexander [1] https://gerrit.ovirt.org/c/86496/

2 1

[ OST Failure Report ] [ oVirt hc master ] [ 19-01-2018 ] [ 002_bootstrap.add_hosts ]
by Dafna Ron 22 Jan '18

22 Jan '18

Hi, we are failing hc master basic suite on test: 002_bootstrap.add_hosts *Link and headline of suspected patches: Link to Job:http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/1… <http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/163/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/… <http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic-suite-master/163/a…>(Relevant) error snippet from the log: <error>*2018-01-18 22:30:56,141-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) [3e58f8ce] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during installation of Host lago_basic_suite_hc_host0: Failed to execute stage 'Closing up': 'Plugin' object has no attribute 'exist' *</error>*

3 2

Subject: [ OST Failure Report ] [ oVirt Master ] [ Jan 15th 2018 ] [ 006_migrations.migrate_vm ]
by Dafna Ron 19 Jan '18

19 Jan '18

Hi, We had a failure in test 006_migrations.migrate_vm <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/testRepo…>. the migration failed with reason "VMExists" Seems to be an issue which is caused by connectivity between engine and hosts. I remember this issue happening before a few weeks ago - is there a solution/bug for this issue? *Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/86114/4 <https://gerrit.ovirt.org/#/c/86114/4> - net tests: Fix vlan creation name length in nettestlib Link to Job:* *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/ <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/art… <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/artifact/>(Relevant) error snippet from the log: <error>* *vdsm dst:2018-01-15 06:47:03,355-0500 ERROR (jsonrpc/0) [api] FINISH create error=Virtual machine already exists (api:124)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 117, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/API.py", line 180, in create raise exception.VMExists()VMExists: Virtual machine already exists* *vdsm src: 2018-01-15 06:47:03,359-0500 ERROR (migsrc/d17a2482) [virt.vm] *(vmId='d17a2482-4904-4cbc-8d13-3a3b7840782d') migration destination error: Virtual machine already exists (migration:290 *)* *Engine: 2018-01-15 06:45:30,169-05 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Failure to refresh host 'lago-basic-suite-master-host-0' runtime info: java.net.ConnectException: Connection refused2018-01-15 06:45:30,169-05 DEBUG [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Exception: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: java.net.ConnectException: Connection refused at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createNetworkException(VdsBrokerCommand.java:159) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:122) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:387) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown Source) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source) [:1.8.0_151] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12) [common.jar:] at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source) [:1.8.0_151] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151] at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68) [weld-core-impl-2.4.3.Final.jar:2.4.3.Final] at org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown Source) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:647) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refreshVdsRunTimeInfo(HostMonitoring.java:118) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refresh(HostMonitoring.java:85) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refresh(VdsManager.java:267) [vdsbroker.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_151] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [rt.jar:1.8.0_151] at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383) [javax.enterprise.concurrent-1.0.jar:] at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534) [javax.enterprise.concurrent-1.0.jar:] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151] 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)Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) [rt.jar:1.8.0_151] at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717) [rt.jar:1.8.0_151] at org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient.connect(ReactorClient.java:118) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.getClient(JsonRpcClient.java:160) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:93) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.FutureMap.<init>(FutureMap.java:70) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer.getCapabilities(JsonRpcVdsServer.java:314) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:22) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:112) [vdsbroker.jar:] ... 34 more2018-01-15 06:45:30,170-05 DEBUG [org.ovirt.engine.core.vdsbroker.VdsManager] (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Failed to refresh VDS, network error, continuing, vds='lago-basic-suite-master-host-0'(31f09289-ec6c-42ff-a745-e82e8ac8e6b9): java.net.ConnectException: Connection refused* *</error>*

5 5