[Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi, I'm experiencing a strange UI bug in the Amdin Portal. The "Virtual Machines" tab is unusable in serval ways: - when selecting a VM, all buttons are greyed-out, except "New VM" - you cannot power on, power off, open console or edit a VM - when selecting a VM, the VM-specific tabs do not appear on the bottom All other tabs, especially the "Hosts" tab are working as expected. Initially I suspected an incompatible browser on my side, so I tried with Firefox 25, Chrome and IE 11. No success. This UI bug hit me after upgrading from oVirt 3.3.0 to 3.3.1. And it is still reproducable in oVirt 3.3.2 BETA1. Any hint on this? Or any advice how to provide some useful debug output? I have to mention that I am able to workaround this bug: - select a VM - right click, choose "New VM", click "Cancel" - now most VM actions are no longer greyed-out - power on the VM - still the "console" button remains greyed-out Thanks - Frank
adding Tomas, he may know… On Dec 9, 2013, at 11:41 , Frank Wall <fw@moov.de> wrote:
Hi,
I'm experiencing a strange UI bug in the Amdin Portal. The "Virtual Machines" tab is unusable in serval ways:
- when selecting a VM, all buttons are greyed-out, except "New VM" - you cannot power on, power off, open console or edit a VM - when selecting a VM, the VM-specific tabs do not appear on the bottom
All other tabs, especially the "Hosts" tab are working as expected.
Initially I suspected an incompatible browser on my side, so I tried with Firefox 25, Chrome and IE 11. No success.
This UI bug hit me after upgrading from oVirt 3.3.0 to 3.3.1. And it is still reproducable in oVirt 3.3.2 BETA1.
Any hint on this? Or any advice how to provide some useful debug output?
I have to mention that I am able to workaround this bug:
- select a VM - right click, choose "New VM", click "Cancel" - now most VM actions are no longer greyed-out - power on the VM - still the "console" button remains greyed-out
Thanks - Frank _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Frank, could you please attach the frontend logs from FF if there are any exceptions? You can do it by: Tools -> Web Developer -> Error Console and than refresh the browser and navigate to the tabs where the issues are. Thanx, Tomas ----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 10:41:22 AM Subject: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi,
I'm experiencing a strange UI bug in the Amdin Portal. The "Virtual Machines" tab is unusable in serval ways:
- when selecting a VM, all buttons are greyed-out, except "New VM" - you cannot power on, power off, open console or edit a VM - when selecting a VM, the VM-specific tabs do not appear on the bottom
All other tabs, especially the "Hosts" tab are working as expected.
Initially I suspected an incompatible browser on my side, so I tried with Firefox 25, Chrome and IE 11. No success.
This UI bug hit me after upgrading from oVirt 3.3.0 to 3.3.1. And it is still reproducable in oVirt 3.3.2 BETA1.
Any hint on this? Or any advice how to provide some useful debug output?
I have to mention that I am able to workaround this bug:
- select a VM - right click, choose "New VM", click "Cancel" - now most VM actions are no longer greyed-out - power on the VM - still the "console" button remains greyed-out
Thanks - Frank _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Tomas, Am 2013-12-09 10:47, schrieb Tomas Jelinek:
could you please attach the frontend logs from FF if there are any exceptions?
not much, but this is what I got: http://pastebin.com/5p3PbSRG Thanks - Frank
----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "Tomas Jelinek" <tjelinek@redhat.com> Cc: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 11:08:14 AM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi Tomas,
Am 2013-12-09 10:47, schrieb Tomas Jelinek:
could you please attach the frontend logs from FF if there are any exceptions?
not much, but this is what I got: http://pastebin.com/5p3PbSRG
Quite a lot actually - seems like a class cast exception. Let me compile that exact version of oVirt and see what that actually says. Just to make sure to avoid unnecessary compilation: this logs are from 3.3.2 BETA1, right?
Thanks - Frank
Hi Tomas, On 2013-12-09 11:12, Tomas Jelinek wrote:
Just to make sure to avoid unnecessary compilation: this logs are from 3.3.2 BETA1, right?
yes, it's 3.3.2 BETA1 as of yesterday: ovirt-engine-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-backend-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-cli-3.3.0.6-1.fc19.noarch ovirt-engine-dbscripts-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-lib-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-restapi-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-sdk-python-3.3.0.8-1.fc19.noarch ovirt-engine-setup-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-setup-plugin-allinone-3.3.1-2.fc19.noarch ovirt-engine-tools-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-userportal-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-webadmin-portal-3.3.2-0.1.beta1.fc19.noarch ovirt-engine-websocket-proxy-3.3.2-0.1.beta1.fc19.noarch ovirt-host-deploy-1.1.2-1.fc19.noarch ovirt-host-deploy-java-1.1.2-1.fc19.noarch ovirt-host-deploy-offline-1.1.2-1.fc19.noarch ovirt-image-uploader-3.3.1-1.fc19.noarch ovirt-iso-uploader-3.3.1-1.fc19.noarch ovirt-log-collector-3.3.1-1.fc19.noarch ovirt-release-fedora-9-1.noarch Thanks - Frank
Hey Frank, so according to the logs it seems that it failed in AsyncDataProvider.hasSpiceSupport(...) because of access to the map failed on NPE. Problem is that there are two accesses to map. So, there are two possibilities what happened: 1: the OsRepository query failed (to verify this please attach the engine logs (the part right after you log into webadmin - the values get cached and not requested anymore) 2: spiceSupportMatrix.get(osId) returned null. This could be because of the OS of ANY of the VMs currently shown in the VM list is not present in libosinfo config. I would guess this is the issue. To verify this could you please paste here the content of all .../osinfo.conf.d/*.properties and also the result of "select os, vm_name from vm_static" DB query so we can find which value is not there. Thanx, Tomas ----- Original Message -----
From: "Tomas Jelinek" <tjelinek@redhat.com> To: "Frank Wall" <fw@moov.de> Cc: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 11:12:28 AM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "Tomas Jelinek" <tjelinek@redhat.com> Cc: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 11:08:14 AM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi Tomas,
Am 2013-12-09 10:47, schrieb Tomas Jelinek:
could you please attach the frontend logs from FF if there are any exceptions?
not much, but this is what I got: http://pastebin.com/5p3PbSRG
Quite a lot actually - seems like a class cast exception. Let me compile that exact version of oVirt and see what that actually says. Just to make sure to avoid unnecessary compilation: this logs are from 3.3.2 BETA1, right?
Thanks - Frank
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Tomas, On 2013-12-09 14:22, Tomas Jelinek wrote:
2: spiceSupportMatrix.get(osId) returned null. [...] I would guess this is the issue. To verify this could you please paste here the content of all .../osinfo.conf.d/*.properties and also the result of "select os, vm_name from vm_static" DB query so we can find which value is not there.
you're right. I did a lookup in the database and compared the values to the entries in /etc/ovirt-engine/osinfo.conf.d/*.properties. I noticed that the "os" ID 6 is assigned multiple times, but not defined in a .properties file (anymore). A quick check in the Admin Portal confirms this: open "Edit Virtual Machine" => Operating System: null I can't remember what "os" ID 6 was in previous releases. Anyway, since I used this to classify my FreeBSD VMs, I've setup a new file defining it: # cat /etc/ovirt-engine/osinfo.conf.d/freebsd.properties # FreeBSD(6, OsType.BSD, false), os.freebsd.id.value = 6 os.freebsd.name.value = FreeBSD os.freebsd.derivedFrom.value = other os.freebsd.description.value = FreeBSD Operating System os.freebsd.family.value = BSD This fixed my issue, but I still would like to know why ID 6 was silently removed in 3.3.1 :-) Maybe it should be re-added in 3.3.2 to avoid this UI breakage for other people. Thanks - Frank
----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "Tomas Jelinek" <tjelinek@redhat.com> Cc: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 3:56:21 PM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi Tomas,
On 2013-12-09 14:22, Tomas Jelinek wrote:
2: spiceSupportMatrix.get(osId) returned null. [...] I would guess this is the issue. To verify this could you please paste here the content of all .../osinfo.conf.d/*.properties and also the result of "select os, vm_name from vm_static" DB query so we can find which value is not there.
you're right. I did a lookup in the database and compared the values to the entries in /etc/ovirt-engine/osinfo.conf.d/*.properties. I noticed that the "os" ID 6 is assigned multiple times, but not defined in a .properties file (anymore).
A quick check in the Admin Portal confirms this: open "Edit Virtual Machine" => Operating System: null
I can't remember what "os" ID 6 was in previous releases. Anyway, since I used this to classify my FreeBSD VMs, I've setup a new file defining it:
# cat /etc/ovirt-engine/osinfo.conf.d/freebsd.properties # FreeBSD(6, OsType.BSD, false), os.freebsd.id.value = 6 os.freebsd.name.value = FreeBSD os.freebsd.derivedFrom.value = other os.freebsd.description.value = FreeBSD Operating System os.freebsd.family.value = BSD
This fixed my issue, but I still would like to know why ID 6 was silently removed in 3.3.1 :-) Maybe it should be re-added in 3.3.2 to avoid this UI breakage for other people.
Awesome! So I had a look into the history of the osinfo-defaults.properties and the "6" used to be "Other": # Other(6, OsType.Other, false) os.Other.id.value = 6 os.Other.name.value = Other os.Other.derivedFrom.value = Unassigned and it disappeared in this patch: http://gerrit.ovirt.org/#/c/16679/11 @Roy: Any reason this has been removed?
Thanks - Frank
On Dec 9, 2013, at 17:20 , Tomas Jelinek <tjelinek@redhat.com> wrote:
----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "Tomas Jelinek" <tjelinek@redhat.com> Cc: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 3:56:21 PM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi Tomas,
On 2013-12-09 14:22, Tomas Jelinek wrote:
2: spiceSupportMatrix.get(osId) returned null. [...] I would guess this is the issue. To verify this could you please paste here the content of all .../osinfo.conf.d/*.properties and also the result of "select os, vm_name from vm_static" DB query so we can find which value is not there.
you're right. I did a lookup in the database and compared the values to the entries in /etc/ovirt-engine/osinfo.conf.d/*.properties. I noticed that the "os" ID 6 is assigned multiple times, but not defined in a .properties file (anymore).
A quick check in the Admin Portal confirms this: open "Edit Virtual Machine" => Operating System: null
I can't remember what "os" ID 6 was in previous releases. Anyway, since I used this to classify my FreeBSD VMs, I've setup a new file defining it:
# cat /etc/ovirt-engine/osinfo.conf.d/freebsd.properties # FreeBSD(6, OsType.BSD, false), os.freebsd.id.value = 6 os.freebsd.name.value = FreeBSD os.freebsd.derivedFrom.value = other os.freebsd.description.value = FreeBSD Operating System os.freebsd.family.value = BSD
This fixed my issue, but I still would like to know why ID 6 was silently removed in 3.3.1 :-) Maybe it should be re-added in 3.3.2 to avoid this UI breakage for other people.
Awesome!
So I had a look into the history of the osinfo-defaults.properties and the "6" used to be "Other": # Other(6, OsType.Other, false) os.Other.id.value = 6 os.Other.name.value = Other os.Other.derivedFrom.value = Unassigned
and it disappeared in this patch: http://gerrit.ovirt.org/#/c/16679/11
@Roy: Any reason this has been removed?
The removal is correct, we have two different "Other" types (Other, Unassigned) which didn't make sense, but this [1] upgrade script should have taken care of that Is it possible the upgrade went wrong? Thanks, michal [1] http://gerrit.ovirt.org/#/c/16679/11/packaging/dbscripts/upgrade/03_03_0660_...
Thanks - Frank
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 10/12/13 08:50 AM, Michal Skrivanek wrote:
On Dec 9, 2013, at 17:20 , Tomas Jelinek <tjelinek@redhat.com> wrote:
----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "Tomas Jelinek" <tjelinek@redhat.com> Cc: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 3:56:21 PM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi Tomas,
On 2013-12-09 14:22, Tomas Jelinek wrote:
2: spiceSupportMatrix.get(osId) returned null. [...] I would guess this is the issue. To verify this could you please paste here the content of all .../osinfo.conf.d/*.properties and also the result of "select os, vm_name from vm_static" DB query so we can find which value is not there. you're right. I did a lookup in the database and compared the values to the entries in /etc/ovirt-engine/osinfo.conf.d/*.properties. I noticed that the "os" ID 6 is assigned multiple times, but not defined in a .properties file (anymore).
A quick check in the Admin Portal confirms this: open "Edit Virtual Machine" => Operating System: null
I can't remember what "os" ID 6 was in previous releases. Anyway, since I used this to classify my FreeBSD VMs, I've setup a new file defining it:
# cat /etc/ovirt-engine/osinfo.conf.d/freebsd.properties # FreeBSD(6, OsType.BSD, false), os.freebsd.id.value = 6 os.freebsd.name.value = FreeBSD os.freebsd.derivedFrom.value = other os.freebsd.description.value = FreeBSD Operating System os.freebsd.family.value = BSD
This fixed my issue, but I still would like to know why ID 6 was silently removed in 3.3.1 :-) Maybe it should be re-added in 3.3.2 to avoid this UI breakage for other people. Awesome!
So I had a look into the history of the osinfo-defaults.properties and the "6" used to be "Other": # Other(6, OsType.Other, false) os.Other.id.value = 6 os.Other.name.value = Other os.Other.derivedFrom.value = Unassigned
and it disappeared in this patch: http://gerrit.ovirt.org/#/c/16679/11
@Roy: Any reason this has been removed?
The removal is correct, we have two different "Other" types (Other, Unassigned) which didn't make sense, but this [1] upgrade script should have taken care of that Is it possible the upgrade went wrong?
Thanks, michal
[1] http://gerrit.ovirt.org/#/c/16679/11/packaging/dbscripts/upgrade/03_03_0660_...
Hi Frank can you run this so we would know if the script ever ran on your env? psql engine postgres -c "select * from schema_version where version ='03030660';"
Thanks - Frank
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Roy, On 2013-12-10 8:24, Roy Golan wrote:
can you run this so we would know if the script ever ran on your env? psql engine postgres -c "select * from schema_version where version ='03030660';"
engine=# select * from schema_version where version ='03030660'; -[ RECORD 1 ]+--------------------------------------------------------- id | 246 version | 03030660 script | upgrade/03_03_0660_add_enabled_column_to_policy_unit.sql checksum | 5e791c91f298ca662f275e21524e9e30 installed_by | engine started_at | 2013-09-02 20:43:54.8651 ended_at | 2013-09-02 20:43:54.900773 state | INSTALLED current | f comment | Though I'm pretty sure the upgrade process (using `engine-setup`) did not report any error. While grepping through all recent upgrade logs I cannot find any invocation of 03_03_0660_alter_os_type_unassigned_to_other.sql. Thanks - Frank
On 10 Dec 2013, at 15:26, Frank Wall <fw@moov.de> wrote:
Hi Roy,
On 2013-12-10 8:24, Roy Golan wrote: can you run this so we would know if the script ever ran on your env? psql engine postgres -c "select * from schema_version where version ='03030660';"
engine=# select * from schema_version where version ='03030660'; -[ RECORD 1 ]+--------------------------------------------------------- id | 246 version | 03030660 script | upgrade/03_03_0660_add_enabled_column_to_policy_unit.sql checksum | 5e791c91f298ca662f275e21524e9e30 installed_by | engine started_at | 2013-09-02 20:43:54.8651 ended_at | 2013-09-02 20:43:54.900773 state | INSTALLED current | f comment |
Though I'm pretty sure the upgrade process (using `engine-setup`) did not report any error. While grepping through all recent upgrade logs I cannot find any invocation of 03_03_0660_alter_os_type_unassigned_to_other.sql.
So it did run. It was supposed to change the id. Is it possible you so ehow overwrote it manually or anything like that?
Thanks - Frank
On 2013-12-10 14:29, Michal Skrivanek wrote:
So it did run. It was supposed to change the id. Is it possible you so ehow overwrote it manually or anything like that?
No. It is a fresh install from september and I tried hard to follow oVirt's guidelines ;-) I did some manual deletions in engine.async_tasks a while ago to workaround a bug, but this shouldn't have influenced this upgrade task. Regards - Frank
On 10/12/13 03:29 PM, Michal Skrivanek wrote:
On 10 Dec 2013, at 15:26, Frank Wall <fw@moov.de> wrote:
Hi Roy,
On 2013-12-10 8:24, Roy Golan wrote: can you run this so we would know if the script ever ran on your env? psql engine postgres -c "select * from schema_version where version ='03030660';" engine=# select * from schema_version where version ='03030660'; -[ RECORD 1 ]+--------------------------------------------------------- id | 246 version | 03030660 script | upgrade/03_03_0660_add_enabled_column_to_policy_unit.sql checksum | 5e791c91f298ca662f275e21524e9e30 installed_by | engine started_at | 2013-09-02 20:43:54.8651 ended_at | 2013-09-02 20:43:54.900773 state | INSTALLED current | f comment |
Though I'm pretty sure the upgrade process (using `engine-setup`) did not report any error. While grepping through all recent upgrade logs I cannot find any invocation of 03_03_0660_alter_os_type_unassigned_to_other.sql. So it did run. It was supposed to change the id. Is it possible you so ehow overwrote it manually or anything like that?
no it didn't. look at the script name. and Frank says he can't find the name in the log. Something is wrong at this env since the script upgrade/03_03_0660_add_enabled_column_to_policy_unit.sql in the git repo is 03_03_0690 while 03_03_0660 should be the osinfo script. how was this engine installed, upgraded in time? nightly or with official releases? Please also try to "ls /usr/share/ovirt-engine/dbscripts/upgrade | grep unassigned" so we would know if you have the script at all.
Thanks - Frank
Hi Roy, On 2013-12-11 8:18, Roy Golan wrote:
how was this engine installed, upgraded in time? nightly or with official releases?
I'd bet it was installed from an official release, but it seems like it was RC2 back then: Sep 02 17:50:18 Installed: ovirt-engine-setup-3.3.0-0.7.rc2.fc19.noarch 2013-09-02 19:21:24 DEBUG otopi.plugins.ovirt_engine_common.core.misc misc._init:98 Package: ovirt-engine-3.3.0_master (3.3.0-0.7.rc2.fc19)
Please also try to "ls /usr/share/ovirt-engine/dbscripts/upgrade | grep unassigned" so we would know if you have the script at all.
# ls /usr/share/ovirt-engine/dbscripts/upgrade | grep unassigned 03_03_0660_alter_os_type_unassigned_to_other.sql Thanks - Frank
On 2013-12-11 8:18, Roy Golan wrote:
how was this engine installed, upgraded in time? nightly or with official releases?
This is my complete release timeline for this host/engine: Sep 02 17:50:37 Installed: ovirt-engine-3.3.0-0.7.rc2.fc19.noarch Sep 13 22:09:41 Updated: ovirt-engine-3.3.0-3.fc19.noarch Sep 22 18:37:26 Updated: ovirt-engine-3.3.0-4.fc19.noarch Okt 27 21:29:08 Updated: ovirt-engine-3.3.0.1-1.fc19.noarch Dec 05 15:22:38 Updated: ovirt-engine-3.3.1-2.fc19.noarch Dez 08 21:31:55 Updated: ovirt-engine-3.3.2-0.1.beta1.fc19.noarch Regards - Frank
While the question how did this happened I would like to start a parallel discussion about what to do when it happens next time (since this osinfo property files are editable we have to expect that some used OS will be deleted). It is certainly not correct to fail on NPE on FE... I can imagine following options to fix it: - fix only on FE by logic like: if the VM has assigned an OS which is not known, consider it is "other" (e.g. "0") - brings up the question what if the user deletes the "0" from the property file - fix this on engine side and do the magic (e.g. set the "other" if it is undefined) so the FE will never get an incorrectly assigned OS ID - have an "undefined" OS ID hardcoded in the engine which can not be deleted by the user and we can assign it when the actual does not exist - again, we can do this re-assignment on FE or engine - brings up the question what the ID should be and what if the user adds some custom item with this ID - do not transfer OS as ID and than some properties which maps to this IDs but real objects. So we could do instead of: AsyncDataProvider.hasSpiceSupport(getEntity().getOs(), getEntity().getVdsGroupCompatibilityVersion()) something like getEntity().getOs().hasSpiceSupport() So we could have an implementation of "undefined" os which could react appropriately. I like most the last option but at the same time it is quite a big refactoring... What do you think? ----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "Roy Golan" <rgolan@redhat.com> Cc: "oVirt Users" <users@ovirt.org> Sent: Wednesday, December 11, 2013 10:48:15 AM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
On 2013-12-11 8:18, Roy Golan wrote:
how was this engine installed, upgraded in time? nightly or with official releases?
This is my complete release timeline for this host/engine:
Sep 02 17:50:37 Installed: ovirt-engine-3.3.0-0.7.rc2.fc19.noarch Sep 13 22:09:41 Updated: ovirt-engine-3.3.0-3.fc19.noarch Sep 22 18:37:26 Updated: ovirt-engine-3.3.0-4.fc19.noarch Okt 27 21:29:08 Updated: ovirt-engine-3.3.0.1-1.fc19.noarch Dec 05 15:22:38 Updated: ovirt-engine-3.3.1-2.fc19.noarch Dez 08 21:31:55 Updated: ovirt-engine-3.3.2-0.1.beta1.fc19.noarch
Regards - Frank _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Dec 11, 2013, at 13:54 , Tomas Jelinek <tjelinek@redhat.com> wrote:
While the question how did this happened I would like to start a parallel discussion about what to do when it happens next time (since this osinfo property files are editable we have to expect that some used OS will be deleted). It is certainly not correct to fail on NPE on FE...
I can imagine following options to fix it: - fix only on FE by logic like: if the VM has assigned an OS which is not known, consider it is "other" (e.g. "0") - brings up the question what if the user deletes the "0" from the property file
mapping to Other seems to be fine If you delete it "0" well, bad luck;) It also means that with this mapping if you open a running VM and try to save it it may likely fail as it tries to update various fields. Well, bad luck again. I'd address this in bug https://bugzilla.redhat.com/show_bug.cgi?id=1046809 Thanks, michal
- fix this on engine side and do the magic (e.g. set the "other" if it is undefined) so the FE will never get an incorrectly assigned OS ID
- have an "undefined" OS ID hardcoded in the engine which can not be deleted by the user and we can assign it when the actual does not exist - again, we can do this re-assignment on FE or engine - brings up the question what the ID should be and what if the user adds some custom item with this ID
- do not transfer OS as ID and than some properties which maps to this IDs but real objects. So we could do instead of: AsyncDataProvider.hasSpiceSupport(getEntity().getOs(), getEntity().getVdsGroupCompatibilityVersion()) something like getEntity().getOs().hasSpiceSupport() So we could have an implementation of "undefined" os which could react appropriately.
I like most the last option but at the same time it is quite a big refactoring...
What do you think?
----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "Roy Golan" <rgolan@redhat.com> Cc: "oVirt Users" <users@ovirt.org> Sent: Wednesday, December 11, 2013 10:48:15 AM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
On 2013-12-11 8:18, Roy Golan wrote:
how was this engine installed, upgraded in time? nightly or with official releases?
This is my complete release timeline for this host/engine:
Sep 02 17:50:37 Installed: ovirt-engine-3.3.0-0.7.rc2.fc19.noarch Sep 13 22:09:41 Updated: ovirt-engine-3.3.0-3.fc19.noarch Sep 22 18:37:26 Updated: ovirt-engine-3.3.0-4.fc19.noarch Okt 27 21:29:08 Updated: ovirt-engine-3.3.0.1-1.fc19.noarch Dec 05 15:22:38 Updated: ovirt-engine-3.3.1-2.fc19.noarch Dez 08 21:31:55 Updated: ovirt-engine-3.3.2-0.1.beta1.fc19.noarch
Regards - Frank _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
----- Original Message -----
From: "Tomas Jelinek" <tjelinek@redhat.com> To: "Frank Wall" <fw@moov.de> Cc: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 11:47:48 AM Subject: Re: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi Frank,
could you please attach the frontend logs from FF if there are any exceptions? You can do it by: Tools -> Web Developer -> Error Console
Please note that this tools is deprecated in firefox-25.0-3.fc19.x86_64 and should be set explicitly by devtools.errorconsole.enabled preference see for alternatives in https://developer.mozilla.org/en/docs/Error_Console
and than refresh the browser and navigate to the tabs where the issues are.
Thanx, Tomas
----- Original Message -----
From: "Frank Wall" <fw@moov.de> To: "oVirt Users" <users@ovirt.org> Sent: Monday, December 9, 2013 10:41:22 AM Subject: [Users] Strange UI bug: tab "VM" unusable / oVirt 3.3.1+
Hi,
I'm experiencing a strange UI bug in the Amdin Portal. The "Virtual Machines" tab is unusable in serval ways:
- when selecting a VM, all buttons are greyed-out, except "New VM" - you cannot power on, power off, open console or edit a VM - when selecting a VM, the VM-specific tabs do not appear on the bottom
All other tabs, especially the "Hosts" tab are working as expected.
Initially I suspected an incompatible browser on my side, so I tried with Firefox 25, Chrome and IE 11. No success.
This UI bug hit me after upgrading from oVirt 3.3.0 to 3.3.1. And it is still reproducable in oVirt 3.3.2 BETA1.
Any hint on this? Or any advice how to provide some useful debug output?
I have to mention that I am able to workaround this bug:
- select a VM - right click, choose "New VM", click "Cancel" - now most VM actions are no longer greyed-out - power on the VM - still the "console" button remains greyed-out
Thanks - Frank _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (5)
-
Eli Mesika -
Frank Wall -
Michal Skrivanek -
Roy Golan -
Tomas Jelinek