From: "Frank Wall" <fw(a)moov.de&gt; To: "oVirt Users" <users(a)ovirt.org&gt; 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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

From: "Frank Wall" <fw(a)moov.de&gt; To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; Cc: "oVirt Users" <users(a)ovirt.org&gt; 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

Thanks - Frank

From: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; To: "Frank Wall" <fw(a)moov.de&gt; Cc: "oVirt Users" <users(a)ovirt.org&gt; 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(a)moov.de&gt; > To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; > Cc: "oVirt Users" <users(a)ovirt.org&gt; > 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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

From: "Frank Wall" <fw(a)moov.de&gt; To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; Cc: "oVirt Users" <users(a)ovirt.org&gt; 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.

Thanks - Frank

On Dec 9, 2013, at 17:20 , Tomas Jelinek <tjelinek(a)redhat.com&gt; wrote: > > ----- Original Message ----- >> From: "Frank Wall" <fw(a)moov.de&gt; >> To: "Tomas Jelinek" <tjelinek(a)redhat.com&gt; >> Cc: "oVirt Users" <users(a)ovirt.org&gt; >> 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_06...

>> >> >> Thanks >> - Frank >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users

On 10 Dec 2013, at 15:26, Frank Wall <fw(a)moov.de&gt; 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.

Thanks - Frank

> On 10 Dec 2013, at 15:26, Frank Wall <fw(a)moov.de&gt; 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

how was this engine installed, upgraded in time? nightly or with official releases?

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(a)moov.de&gt; > To: "Roy Golan" <rgolan(a)redhat.com&gt; > Cc: "oVirt Users" <users(a)ovirt.org&gt; > 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users