Description of problem: snapshots are not visible in the user portal or webadmin. The snapshots are working though, the snapshot that is selected by default can be manipulated using Preview/Commit/Undo/Delete/Clone buttons however Version-Release number of selected component (if applicable): is16 / 3.3.0-0.22.master.el6ev client: RHEL 6 with Firefox 17 How reproducible: always Steps to Reproduce: 1. create a snapshot of a VM 2. 3. Actual results: no snapshots can be seen Expected results: snapshots are displayed as usual Additional info:
screenshot maybe?
Created attachment 803821 [details] screenshot I can not reproduce anymore on machine with stock Firefox. The problem still reproduces on webadmin when viewed from my Firefox with minimum font size set to 13+ after full page reload (just changing the setting and confirming doesnt make the bug show up/go away).
lowering severity as the bug doesn't hit people with default browser settings.
I have not done any changes to my Firefox profile and I can see same issue. But from time to time. Also other collegues saw it.
any way how to reproduce? Collegues…screenshot at least?:) browser settings?
(In reply to Michal Skrivanek from comment #6) > any way how to reproduce? It's random so use the thing and you'll see it ;) > Collegues…screenshot at least?:) browser settings? attachment 803821 [details] ?
Created attachment 862352 [details] beloved screenshot - two firefox instances
I have no idea how to reproduce this, it just happens from time to time. Thus it is not 'always'.
you say switching between rhevm versions….it might be related to caching…you're sure you cleaned up the cache between each change?
Of course not, why should I? It's bug, we cannot request users to close Firefox and/or clean its cache, (delete their Firefox profile, reinstall operating system, hehe), just to open one web page a have that page working correctly - RHEVM Administration Portal. If so, it would question the sense of having RHEVM Administration Portal as web UI.
AFAIK caching is a known infrastructural problem when switching between versions. @Einav, anything to add here?
Why don't resource names contain the build version? That would also help reload the page after rhev-m upgrade (when thing may go weird without full page reload).
(In reply to Michal Skrivanek from comment #12) > AFAIK caching is a known infrastructural problem when switching between > versions. @Einav, anything to add here? I am not aware of any known caching infrastructural problem. Can someone please detail the exact steps to reproduce, even if not reproducible in 100%? e.g.: ---- 1) install 3.2 2) create snapshot [snapshot displayed correctly] 3) upgrade 3.2 -> 3.3 4) take a look at the snapshots actual results: snapshots sub-tab empty expected results: snapshots sub-tab should contain snapshot created in 3.2. ---- also: did anybody experience anything similar in other tabs/sub-tabs in the system? keep in mind that the snapshots sub-tab is a bit unique / complex than other sub-tabs in the application, there is a good chance that the problem is in that sub-tab in particular. (In reply to David Jaša from comment #13) > Why don't resource names contain the build version? That would also help > reload the page after rhev-m upgrade (when thing may go weird without full > page reload). in each GWT compilation, all of the resources (html/javascript files, etc.) are re-named in random names, so there should not be any kind of cached resources and/or weird behavior once the rhev-m page is refreshed.
(In reply to Einav Cohen from comment #14) > Can someone please detail the exact steps to reproduce, even if not > reproducible in 100%? e.g.: > As already stated: no exact steps are known. The issue pops out randomly but frequently. I understood the more versions thing as using two RHEV portals of different versions at the same time (within browser caching life time). > > did anybody experience anything similar in other tabs/sub-tabs in the > system? No, I did not. > (In reply to David Jaša from comment #13) >... > in each GWT compilation, all of the resources (html/javascript files, etc.) > are re-named in random names, so there should not be any kind of cached > resources and/or weird behavior once the rhev-m page is refreshed. The engine upgrade does not trigger forced reload in my experience and untill user doesn't reload the page explicitly, the behaviour is wrong (broken layout etc.).
(In reply to David Jaša from comment #15) > (In reply to Einav Cohen from comment #14) > > Can someone please detail the exact steps to reproduce, even if not > > reproducible in 100%? e.g.: > > > > As already stated: no exact steps are known. The issue pops out randomly but > frequently. > I understood the more versions thing as using two RHEV portals of different > versions at the same time (within browser caching life time). that's exactly my point - what you understood as "two RHEV portals of different versions at the same time" I understood as "a single RHEV portal that has been upgraded from version x to version y" - I do not understand the scenario *at all*. I need someone to clarify *a* scenario, one scenario - no matter if reproduced only once and never reproduced again - since currently, the problem is completely unclear to me. > > > > > did anybody experience anything similar in other tabs/sub-tabs in the > > system? > > No, I did not. so there is a good chance that the problem is in the snashots sub-tab in particular, and not a general GUI problem. > > > > (In reply to David Jaša from comment #13) > >... > > in each GWT compilation, all of the resources (html/javascript files, etc.) > > are re-named in random names, so there should not be any kind of cached > > resources and/or weird behavior once the rhev-m page is refreshed. > > The engine upgrade does not trigger forced reload in my experience and > untill user doesn't reload the page explicitly, the behaviour is wrong > (broken layout etc.). explicitly reloading the page upon engine upgrade is a completely acceptable requirement; forcing the client to periodically request the engine version from the server just for saving the user a single click on "F5" every couple of months (or more depends on the engine upgrade frequency) seems like a bit of an overkill to me. We need to keep in mind that this application is very much like a client application; would you consider closing and re-opening a client application upon application-upgrade as an unreasonable requirement? has anyone experienced this problem *even after explicitly reloading the page*?
guys, what about the steps to reproduce in the description of bug 1058618 (though in there it is 3.4 and not 3.3)? if you are following these steps to reproduce in your envs, do you get the same behavior of an empty snapshots sub-tab?
I can confirm that this behaviour sounds closely related to BZ 1058618. You neither need an engine upgrade nor several engines. Sorry for being unable to provide better informations but that GWT stuff is nearly impossible to debug. Nevertheless: I checked that even in the error case the json request is fired to get the snapshot list. The result is simply not displayed in the snapshot pane.
> 1) install 3.2 > 2) create snapshot > [snapshot displayed correctly] > 3) upgrade 3.2 -> 3.3 > 4) take a look at the snapshots > > actual results: > snapshots sub-tab empty > > expected results: > snapshots sub-tab should contain snapshot created in 3.2. Tried this and it is OK (clean 3.2, clean client with clean FF, upgraded to 3.3). So reproducing steps are still unknown.
From the above discussion I expected that the tested scenario (snapshot pane is empty after upgrade) is not what the reporter tried to explain. Nice to see that snapshots cannot get lost during upgrades. @David: I advise to reproduce the bug according to BZ 1058618 . At least you can get a non-working snaphot pane quite easily. Maybe you see the same behaviour and we can link these bugs.
(In reply to Einav Cohen from comment #16) ... > > that's exactly my point - what you understood as "two RHEV portals of > different versions at the same time" I understood as "a single RHEV portal > that has been upgraded from version x to version y" \ I'm not native english speaker but this is not according to a description. You can not use pre- and post-upgrade versions at the same time, there is a clear "before" and "after". > - I do not understand > the scenario *at all*. Have two RHEV setups, e.g. one 3.2 and one 3.3, connect to the portal from a single browser session (one tab one portal, another tab for the other portal). Let's leave this anyway, it seems to me as a dead end based on Markus's info. > I need someone to clarify *a* scenario, one scenario - no matter if > reproduced only once and never reproduced again - since currently, the > problem is completely unclear to me. > > has anyone experienced this problem *even after explicitly reloading the > page*? After ctrl+r reload, yes. After ctrl+shift+r reload, no. (In reply to Markus Stockhausen from comment #21) > From the above discussion I expected that the tested scenario (snapshot pane > is empty after upgrade) is not what the reporter tried to explain. Nice to > see that snapshots cannot get lost during upgrades. > > @David: I advise to reproduce the bug according to BZ 1058618 . At least you > can get a non-working snaphot pane quite easily. Maybe you see the same > behaviour and we can link these bugs. I could reproduce so I'm incline to mark this bug as a duplicate of yours.
(In reply to David Jaša from comment #22) > > has anyone experienced this problem *even after explicitly reloading the > > page*? > > After ctrl+r reload, yes. After ctrl+shift+r reload, no. > This has changed recently, ctrl+r is enough in released 3.3.
I will try to summarize the status of this BZ, I apologize if I got something wrong. David/Jiri - please ack/nack: - the bug is not reproducible if browser refresh is performed right after engine upgrade. - the bug is reproducible in the scenario described in Bug 1058618, hence this bug is kind of a "Clone" of Bug 1058618 (if so - BZ subject needs to be updated accordingly)
(In reply to Einav Cohen from comment #24) > I will try to summarize the status of this BZ, I apologize if I got > something wrong. David/Jiri - please ack/nack: > > - the bug is not reproducible if browser refresh is performed right after > engine upgrade. I can't really say as I do engine upgrades quite rarely (as opposed to concurrent use of more RHEV setups or having some of them time out) > - the bug is reproducible in the scenario described in Bug 1058618, hence > this bug is kind of a "Clone" of Bug 1058618 (if so - BZ subject needs to be > updated accordingly) Ack.
let's close this and track the other issue then. *** This bug has been marked as a duplicate of bug 1058618 ***