- Devel - oVirt List Archives

[Engine-devel] oVirt 3.3.3 Release Candidate is now available
by Sandro Bonazzola 22 Jan '14

22 Jan '14

The oVirt team is pleased to announce that the 3.3.3 Release Candidate is now available in ovirt-updates-testing [1]. Feel free to join us testing it[2] and verifying the bugzilla entries actually under verification [3]. Release notes for this update are available on the wiki [4]. A new oVirt Node build will be available soon as well. [1] http://resources.ovirt.org/releases/updates-testing [2] http://www.ovirt.org/Testing/Ovirt_3.3.3_testing [3] http://red.ht/KEesdK [4] http://www.ovirt.org/OVirt_3.3.3_release_notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[Engine-devel] proposing Alexander Wels as an ovirt-engine UI maintainer
by Einav Cohen 21 Jan '14

21 Jan '14

Hello UI Maintainers, I would like to propose Alexander Wels as an ovirt-engine UI maintainer. Alexander started his ovirt involvement more than a year ago, contributing over 100 patches (to 'master' alone), including the branding mechanism, Frontend refactoring (cleanup, unit-tests, requests retry mechanism, requests-aggregation mechanism), cross-GUI refresh synchronization and low-resolutions support. Your response would be appreciated. Thanks in advance. ---- Regards, Einav

11 10

[Engine-devel] Copy reviewer scores on trivial rebase/commit msg changes
by Itamar Heim 21 Jan '14

21 Jan '14

I'd like to enable these - comments welcome: 1. label.Label-Name.copyAllScoresOnTrivialRebase If true, all scores for the label are copied forward when a new patch set is uploaded that is a trivial rebase. A new patch set is considered as trivial rebase if the commit message is the same as in the previous patch set and if it has the same code delta as the previous patch set. This is the case if the change was rebased onto a different parent. This can be used to enable sticky approvals, reducing turn-around for trivial rebases prior to submitting a change. Defaults to false. 2. label.Label-Name.copyAllScoresIfNoCodeChange If true, all scores for the label are copied forward when a new patch set is uploaded that has the same parent commit as the previous patch set and the same code delta as the previous patch set. This means only the commit message is different. This can be used to enable sticky approvals on labels that only depend on the code, reducing turn-around if only the commit message is changed prior to submitting a change. Defaults to false. https://gerrit-review.googlesource.com/Documentation/config-labels.html

6 9

[Engine-devel] Fast Forward or Rebase if necessary policies
by Itamar Heim 21 Jan '14

21 Jan '14

Today we use the 'fast forward only' policy in gerrit. It seems the 'rebase if necessary' policy may reduce some overhead, as it will solve trivial rebases before the merge (it will fail on any conflict, or any change to same file, even if no conflict). I'm suggesting moving to try and move to 'rebase if necessary' for ovirt-engine repo, and see if we think we are facing issues, or just enjoying the benefits of not having to click merge, fail, rebase, review+merge again. the one caveat i can think of is if the patch is old, it should probably be rebased for the various jenkins jobs to run on it again, but I think for most patches that's not the case. (vdsm is using an even less strict policy of cherry-pick) thoughts? Thanks, Itamar

2 2

[Engine-devel] feature page for Authentication Rewrite
by Yair Zaslavsky 21 Jan '14

21 Jan '14

Hi all, I wrote a wiki page for the authentication rewrite effort that Juan Hernandez and I worked on http://www.ovirt.org/Features/Authentication-Rewrite Feel free to share your comments.

1 0

Re: [Engine-devel] [rhev-devel] login and first opened tabs in webadmin
by Malini Rao 20 Jan '14

20 Jan '14

[top posting] My 2 cents - I think fixing the bug about the semi persistent tree selection is very important since it can completely disorient and confuse users. I am uncomfortable about letting it slide until we deal with the RFE filed. We have introduced a feature where we are now allowing users to collapse the tree to reclaim real estate. While this is a good thing, this can also further worsen these kinds of sudden and automatic scope changes. Even if the tree is expanded, these kinds of automatic scope changes upon refresh are not advisable. +1 for the RFE itself - I think persisting the last state at log off is always a good thing. Many people may be working on tasks within a certain scope for many days at a time and if the app resets to system level each time and that too unpredictably after 5-10s, it is annoying to go back and drill to where they were. Based on my conversations with customers about their setups so far, not a lot of them seem to have multiple DCs and hopefully permissions will take care of some of the filtering of entities that are not relevant. Having said all of these, I still feel persistence of scope selection will be a positive experience. Thanks Malini ----- Original Message ----- From: "Eldan Hildesheim" <ehildesh(a)redhat.com> To: "Malini Rao" <mrao(a)redhat.com> Sent: Monday, January 20, 2014 10:28:27 AM Subject: Fwd: [rhev-devel] login and first opened tabs in webadmin ----- Forwarded Message ----- From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com> To: "Einav Cohen" <ecohen(a)redhat.com> Cc: "rhev-devel" <rhev-devel(a)redhat.com> Sent: Monday, January 20, 2014 5:13:19 PM Subject: Re: [rhev-devel] login and first opened tabs in webadmin On Jan 20, 2014, at 14:58 , Einav Cohen <ecohen(a)redhat.com> wrote: >> ----- Original Message ----- >> From: "Itamar Heim" <iheim(a)redhat.com> >> Sent: Sunday, January 19, 2014 8:46:43 AM >> >> On 01/19/2014 01:55 PM, Eldan Hildesheim wrote: >>> Hi, >>> As I see it, the RFE is a "nice to have" and not more then that. >>> I don't see any problem with the following scenario: >>> >>> -login to the system >>> -click a specific DC in the tree and now you will work only under that >>> scope. >>> >>> Again it's nice but not necessary (gmail don't have this option) >>> In this way or the other the issue of the following bug will raise: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1049320 >>> >>> Eldan >> >> just remember the last place the user was on for next time they login >> (main tab, and tree if exists)? > > sure, no one objects here. > @Michal - can you please open the RFE (and the BZ) as I requested earlier, > since you raised these issues? many thanks in advance. opened RFE https://bugzilla.redhat.com/show_bug.cgi?id=1055587 I think the other bug will be addressed by fixing the RFE so no need for a separate bug (not that urgent anyway) Thanks, michal > >> >>> >>> >>> ----- Original Message ----- >>> From: "Einav Cohen" <ecohen(a)redhat.com> >>> To: "Vojtech Szocs" <vszocs(a)redhat.com> >>> Cc: "Gilad Chaplik" <gchaplik(a)redhat.com>, "rhev-devel" >>> <rhev-devel(a)redhat.com> >>> Sent: Thursday, January 16, 2014 5:52:02 PM >>> Subject: Re: [rhev-devel] login and first opened tabs in webadmin >>> >>>>> In any case the persistence of last selected tree item and a main tab >>>>> would >>>>> be nice, I was just wondering if a similar bug exists already (I would >>>>> think so) >>> >>> there is no such issue reported (maybe it is not with 'ux' Whiteboard). >>> >>>> 1, [bug] select DC in tree, log out, log in >>>> - for short time period, DC is still selected in tree (instead of >>>> "System") >>>> - after this time, tree selection is reset (probably due to data >>>> refresh) >>>> >>>> 2, [RFE] remember tree & main tab selection locally on client >>>> - apply previous selection right after each login >>>> >>>> Hope I got it right :) >>> >>> correct. >>> @Michal - feel free to open the two BZs as detailed above. >>> >>> ---- >>> Thanks, >>> Einav >>> >>> ----- Original Message ----- >>>> From: "Vojtech Szocs" <vszocs(a)redhat.com> >>>> To: "Michal Skrivanek" <michal.skrivanek(a)redhat.com> >>>> Cc: "Einav Cohen" <ecohen(a)redhat.com>, "Tomas Jelinek" >>>> <tjelinek(a)redhat.com>, "Daniel Erez" <derez(a)redhat.com>, >>>> "Gilad Chaplik" <gchaplik(a)redhat.com>, "Greg Sheremeta" >>>> <gshereme(a)redhat.com>, "Lior Vernia" <lvernia(a)redhat.com>, >>>> "rhev-devel" <rhev-devel(a)redhat.com> >>>> Sent: Thursday, January 16, 2014 9:52:37 AM >>>> Subject: Re: [rhev-devel] login and first opened tabs in webadmin >>>> >>>> Hi, as discussed with Michal there are two issues: >>>> >>>> 1, [bug] select DC in tree, log out, log in >>>> - for short time period, DC is still selected in tree (instead of >>>> "System") >>>> - after this time, tree selection is reset (probably due to data >>>> refresh) >>>> >>>> 2, [RFE] remember tree & main tab selection locally on client >>>> - apply previous selection right after each login >>>> >>>> Hope I got it right :) >>>> >>>> Vojtech >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com> >>>>> To: "Einav Cohen" <ecohen(a)redhat.com> >>>>> Cc: "Tomas Jelinek" <tjelinek(a)redhat.com>, "Daniel Erez" >>>>> <derez(a)redhat.com>, "Gilad Chaplik" <gchaplik(a)redhat.com>, >>>>> "Greg Sheremeta" <gshereme(a)redhat.com>, "Vojtech Szocs" >>>>> <vszocs(a)redhat.com>, "Lior Vernia" <lvernia(a)redhat.com>, >>>>> "rhev-devel" <rhev-devel(a)redhat.com> >>>>> Sent: Thursday, January 16, 2014 3:20:54 PM >>>>> Subject: Re: [rhev-devel] login and first opened tabs in webadmin >>>>> >>>>> >>>>> On Jan 15, 2014, at 15:10 , Einav Cohen <ecohen(a)redhat.com> wrote: >>>>> >>>>>> Hi Michal, I apologize - I have not idea what you are talking about. >>>>>> UI Guys: Are you familiar with an automatic selection of the last- >>>>>> selected-tree-node from the previous session? >>>>>> are we persisting anything with regards to the tree? >>>>> >>>>> talked with Vojtech briefly…we're not persisting anything yet, which is a >>>>> pity, because everytime I open webadmin I'm presented with a huge list of >>>>> Vms I do not care about….but what is actually confusing is that after the >>>>> reopen the left hand tree is still showing my selected data center until >>>>> next refresh (~5-10s) which Vojtech believes is a bug >>>>> >>>>> In any case the persistence of last selected tree item and a main tab >>>>> would >>>>> be nice, I was just wondering if a similar bug exists already (I would >>>>> think >>>>> so) >>>>> >>>>> Thanks, >>>>> michal >>>>> >>>>>> ---- >>>>>> Thanks, >>>>>> Einav >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Michal Skrivanek" <michal.skrivanek(a)redhat.com> >>>>>>> To: "Einav Cohen" <ecohen(a)redhat.com> >>>>>>> Cc: "rhev-devel" <rhev-devel(a)redhat.com> >>>>>>> Sent: Wednesday, January 15, 2014 3:18:36 AM >>>>>>> Subject: login and first opened tabs in webadmin >>>>>>> >>>>>>> Hi, >>>>>>> I suppose it's a well known ux issue that after logging in we always go >>>>>>> to >>>>>>> the Virtual Machines tab. Well, so far ok, let's say, but when I have >>>>>>> multiple data enters this makes no sense. I see all the machines, >>>>>>> almost >>>>>>> all >>>>>>> not related to me whatsoever. >>>>>>> It's also quite confusing as during the first 5-10s the left hand tree >>>>>>> shows >>>>>>> my previous selection of the specific data center so I expect the list >>>>>>> to >>>>>>> be >>>>>>> filtered. After that long period of time the tree reloads and resets to >>>>>>> System level. >>>>>>> This is at rhev tlv. >>>>>>> >>>>>>> Are we fixing this?:) At least the semi-persistence we have for other >>>>>>> stuff >>>>>>> (per user in LocalStorage) would be better than nothing. >>>>>>> >>>>>>> Thanks, >>>>>>> michal >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >>

1 0

[Engine-devel] About VM tools(drivers) on oVirt's VM? move mouse have long latency.
by JustMan 20 Jan '14

20 Jan '14

This is a multi-part message in MIME format. ------=_NextPart_52D8A02F_08A06230_0EFD7975 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIEFsbDoNCiAgDQogICAgSSBpbnN0YWxsIGJvdGggb1ZpcnQgZW5naW5lIGFuZCBub2Rl cywgaXQncyBjYW4gd29yayB3aXRoIFNQSUNFIGNsaWVudCwgYnV0IHRoZSBWTSBsYWNrIG9m IGRyaXZlcnMgKGxpa2Ugdm13YXJlIHN0YXRpb24ncyB0b29scyApLCBzbyB3aGVuIHlvdSBj b25uZWN0ZWQgVk0gaXQncyBvcGVyYXRpb24gdmVyeSBzbG93LS0gSSBtZWFuIG9wZXJhdGlv biBpbiBWTSBub3Qgc21vb3RobmVzcywgbGlrZSBtb3ZlIG1vdXNlIGhhdmUgbG9uZyBsYXRl bmN5Lg0KICANCiAgICBBbmQgdGhlICJWaXJ0SU8gQ29uc29sZSBEZXZpY2UgRW5hYmxlZCAi ICYgIlZpcnRJTy1TQ1NJIEVuYWJsZWQiIG9wdGlvbiBpdCBzZWVtcyBub3Qgd29yay4NCiAg DQogICAgSG93IGNhbiBzb2x2ZSB0aGlzIHByb2JsZW0gPyBJIHdhbnQgdG8gdXNlIG9WaXJ0 IGFzIGEgY2xvdWQgZGVza3RvcCBnaXZlIHVzZXIgZm9yIHJlcGxhY2UgZGVza3RvcCBQQyBh bmQgbm90ZWJvb2ssIElmIHRoZSBsYXRlbmN5IHNvIGxvbmcsIEkgdGhpbmsgVXNlciB3aWxs IG5vdCBBY2NlcHQuDQogIA0KICAgIFRoZXJlIGFyZSBhbnkgYWRkLW9uIGRyaXZlcnMgb3Ig dG9vbHMgbmVlZCBpbnN0YWxsIGludG8gVk0gPyBXaGVyZSBjYW4gZG93bmxvYWQgaXQ/DQog IA0KIE1hbnkgdGhhbmtzIQ0KIHJlZ2FyZHMNCiAgDQogaWtlIA0KICANCiAyMDE0LTAxLTE3 ------=_NextPart_52D8A02F_08A06230_0EFD7975 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PERJVj5IaSwgQWxsOjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5i c3A7IEkgaW5zdGFsbCBib3RoJm5ic3A7b1ZpcnQgZW5naW5lIGFuZCBub2RlcywgaXQncyBj YW4gd29yayB3aXRoIFNQSUNFIGNsaWVudCwgYnV0IHRoZSBWTSBsYWNrIG9mIGRyaXZlcnMg KGxpa2Ugdm13YXJlIHN0YXRpb24ncyB0b29scyApLCBzbyB3aGVuIHlvdSBjb25uZWN0ZWQg Vk0gaXQncyBvcGVyYXRpb24gdmVyeSBzbG93LS0gSSBtZWFuIG9wZXJhdGlvbiBpbiBWTSBu b3Qgc21vb3RobmVzcywgbGlrZSBtb3ZlIG1vdXNlJm5ic3A7aGF2ZSBsb25nIGxhdGVuY3ku PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsgQW5kIHRoZSAi VmlydElPJm5ic3A7Q29uc29sZSZuYnNwO0RldmljZSZuYnNwO0VuYWJsZWQgIiAmYW1wOyAi VmlydElPLVNDU0kgRW5hYmxlZCIgb3B0aW9uIGl0IHNlZW1zIG5vdCB3b3JrLjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7IEhvdyBjYW4gc29sdmUgdGhp cyBwcm9ibGVtID8gSSB3YW50IHRvIHVzZSBvVmlydCBhcyBhIGNsb3VkJm5ic3A7ZGVza3Rv cCBnaXZlJm5ic3A7dXNlciBmb3IgcmVwbGFjZSZuYnNwO2Rlc2t0b3AgUEMgYW5kIG5vdGVi b29rLCBJZiB0aGUgbGF0ZW5jeSBzbyBsb25nLCBJIHRoaW5rIFVzZXIgd2lsbCBub3QgQWNj ZXB0LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7IFRoZXJl IGFyZSBhbnkgYWRkLW9uIGRyaXZlcnMgb3IgdG9vbHMgbmVlZCBpbnN0YWxsIGludG8gVk0g PyBXaGVyZSBjYW4gZG93bmxvYWQgaXQ/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5NYW55IHRoYW5rcyE8L0RJVj4NCjxESVY+cmVnYXJkczwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+aWtlIDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+MjAxNC0w MS0xNzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4= ------=_NextPart_52D8A02F_08A06230_0EFD7975--

4 5

[Engine-devel] [BUG] in UserMapper.java in 3.3.2
by Sven Kieske 17 Jan '14

17 Jan '14

Hi, afaik there's a bug in 3.3.2 rest-api implementation of Cloud-Init: This Class never gets the password: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/… and I think there is a typo in line 48: vdcUser.setDomainControler(adUser.getDomainControler it should be Controller, not Controler. there is no model.setPassword or similar. so the data gets to the vm without the password, can somebody fix this? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

2 3

[Engine-devel] [QE] oVirt 3.4.0 alpha / beta status
by Sandro Bonazzola 17 Jan '14

17 Jan '14

Hi, oVirt 3.4.0 alpha has been released and is actually on QA. An issue has been found in VDSM so we have updated the packages in alpha repositories for Fedora. We had an issue with nightly build for EL6 packages yesterday so EL6 repository is not yet updated. We'll try to sync it today, I'm sorry for the inconvenient. We'll start composing oVirt 3.4.0 beta on 2014-01-20 14:00 UTC from 3.4 branches. The bug tracker [1] shows the following bugs blocking the release: Whiteboard Bug ID Summary gluster 1038988 Gluster brick sync does not work when host has multiple interfaces integration 1054080 gracefully warn about unsupported upgrade from legacy releases network 1054195 [NetworkLabels] Attaching two labeled networks to a cluster result in failure of the latter There are still 280 bugs [2] targeted to 3.4.0. Excluding node and documentation bugs we still have 237 bugs [3] targeted to 3.4.0. Please review them as soon as possible. Maintainers: - Please remember to rebuild your packages before 2014-01-21 12:00 UTC if you want them to be included in 3.4.0 beta. - Please add the bugs to the tracker if you think that 3.4.0 should not be released without them fixed. - Please provide ETA on blockers bugs - Please update the target to 3.4.1 or any next release for bugs that won't be in 3.4.0: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - Please update http://www.ovirt.org/OVirt_3.4_TestDay before 2014-01-23 For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug. Please also be prepared for upcoming oVirt 3.4.0 Test Day on 2014-01-23! Thanks to all people already testing 3.4.0 alpha! [1] https://bugzilla.redhat.com/1024889 [2] http://red.ht/1eIRZXM [3] http://red.ht/1auBU3r [4] http://www.ovirt.org/OVirt_3.4.0_release_notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

4 6

[Engine-devel] [QE] oVirt 3.3.3 beta / RC status
by Sandro Bonazzola 17 Jan '14

17 Jan '14

Hi, oVirt 3.3.3 beta has been released and is actually on QA. We'll start composing oVirt 3.3.3 RC on 2014-01-21 12:00 UTC. The bug tracker [1] shows no bugs blocking the release The following is a list of the non-blocking bugs still open with target 3.3 - 3.3.3: Whiteboard Bug ID Summary integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 [RFE] oVirt Live - use motd to show the admin password integration 1022440 [RFE] AIO - configure the AIO host to be a gluster cluster/host integration 1026930 Package virtio-win and put it in ovirt repositories integration 1026933 pre-populate ISO domain with virtio-win ISO integration 1050084 Tracker: oVirt 3.3.3 release network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural) node 906257 USB Flash Drive install of ovirt-node created via dd fails node 923049 ovirt-node fails to boot from local disk under UEFI mode node 965583 [RFE] add shortcut key on TUI node 976675 [wiki] Update contribution page node 979350 Changes admin password in the first time when log in is failed while finished auto-install node 979390 [RFE] Split defaults.py into smaller pieces node 982232 performance page takes >1sec to load (on first load) node 984441 kdump page crashed before configuring the network after ovirt-node intalled node 986285 UI crashes when no bond name is given node 991267 [RFE] Add TUI information to log file. node 1018374 ovirt-node-iso-3.0.1-1.0.2.vdsm.fc19: Failed on Auto-install node 1018710 [RFE] Enhance API documentation node 1032035 [RFE]re-write auto install function for the cim plugin node 1033286 ovirt-node-plugin-vdsm can not be added to ovirt node el6 base image storage 987917 [oVirt] [glance] API version not specified in provider dialog virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain Maintainers: - We'll start composing oVirt 3.3.3 RC on 2014-01-21 12:00 UTC: all non blockers bug still open after the build will be moved to 3.3.4. - Please add the bugs to the tracker if you think that 3.3.3 should not be released without them fixed. - Please provide ETA on bugs you add as blockers - Please re-target all bugs you don't think that should block 3.3.3. - Please fill release notes, the page has been created here [3] - Please remember to rebuild your packages before 2014-01-21 12:00 UTC if you want them to be included in 3.3.3 RC. For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2]. Thanks to Gianluca Cecchi for his testing of oVirt 3.3.3 beta on Gluster storage! [1] http://bugzilla.redhat.com/1050084 [2] http://www.ovirt.org/Testing/Ovirt_3.3.3_testing [3] http://www.ovirt.org/OVirt_3.3.3_release_notes Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0