Re: [Engine-devel] [rhev-devel] login and first opened tabs in webadmin
by Malini Rao
[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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
10 years, 9 months
[Engine-devel] About VM tools(drivers) on oVirt's VM? move mouse have long latency.
by JustMan
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--
10 years, 9 months
[Engine-devel] [BUG] in UserMapper.java in 3.3.2
by Sven Kieske
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/manage...
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
10 years, 9 months
[Engine-devel] [QE] oVirt 3.4.0 alpha / beta status
by Sandro Bonazzola
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
10 years, 9 months
[Engine-devel] [QE] oVirt 3.3.3 beta / RC status
by Sandro Bonazzola
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
10 years, 9 months
[Engine-devel] [QE] oVirt bugzilla updates
by Sandro Bonazzola
Hi oVirt community,
for all people interested in joining QE effort, we've created a new user in bugzilla as default QA assignee: bugs(a)ovirt.org.
If you want to be updated on QE bugs activity you can just add that user to your bugzilla account watch list:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
Watch user list -> add "bugs(a)ovirt.org"
Any email sent by bugzilla to that user will be also sent to you.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 9 months
[Engine-devel] ovirt-engine 3.4.0 branching
by Sandro Bonazzola
Hi,
this is the last call for pending patches on master branch for ovirt-engine.
The ovirt-engine-3.4 branch will be created at 9:00 AM UTC (11:00 AM Israel time).
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 9 months
[Engine-devel] stripping ' from log messages
by Jiri Moskovcak
Hi,
while working on a patch for engine I ran into a code which removes '
from log messages. It's in Log.java: 165 method transform. Seems like
it's there since the conversion to java happened. This code cripples the
log messages i.e can't -> cant, it's -> its ..etc. Is there some reason
why it's there? Or could it be removed?
Thank you,
Jirka
10 years, 9 months
[Engine-devel] Showing stacktrace info in GUI error dialog
by Einav Cohen
Hi, this is about patch [1] - showing server-side-exception
stacktrace info in GUI error dialog.
a couple of notes about this patch:
(1) I find it a little strange that server-side exceptions
are not logged in the server side and are / will be displayed
only on the client-side - this needs to be fixed first.
(2) once everything is logged on the server side, we can
debate whether it makes sense to put the full exception
stack-trace *also* in the GUI error pop-up.
I think that it is not completely necessary (since if there
is a server side exception, the user is likely to go to the
server side log anyway to get the full picture / context), but
if it is (and I'd like to hear your opinion about that) - we
shouldn't show the entire exception in the dialog once the dialog
is displayed - that's too much information to absorb.
We should show whatever we are showing today, and also something
like a "More Details" collapsible section (collapsed by default)
that, when expanded, displays the full exception details.
comments are welcome.
----
Thanks,
Einav
[1] http://gerrit.ovirt.org/#/c/23096/
10 years, 9 months
