Bug 2139790 - RHOSP16.2.3: Snapshot image Metadata cannot be updated in horizon due to empty os_hash_algo or os_hash_value
Summary: RHOSP16.2.3: Snapshot image Metadata cannot be updated in horizon due to empt...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-django-horizon
Version: 16.2 (Train)
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: z5
: 16.2 (Train on RHEL 8.4)
Assignee: Tatiana Ovchinnikova
QA Contact: ikanias
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-03 12:59 UTC by Shravan Kumar Tiwari
Modified: 2023-09-19 04:29 UTC (History)
6 users (show)

Fixed In Version: python-django-horizon-16.2.3-2.20230227155029.d3d3d18.el8ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-04-26 12:17:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 864062 0 None MERGED Make readonly metadata properties unable to edit 2023-01-23 17:28:14 UTC
Red Hat Issue Tracker OSP-19887 0 None None None 2022-11-03 13:17:20 UTC
Red Hat Product Errata RHBA-2023:1763 0 None None None 2023-04-26 12:17:51 UTC

Description Shravan Kumar Tiwari 2022-11-03 12:59:10 UTC
Description of problem:
Snapshot image edit does not allow to update metadata due to empty os_hash_algo or os_hash_value

Version-Release number of selected component (if applicable):
RHOSP16.2.3

How reproducible:

1.Create instance, "do not create volume", wait for instance to be ready.
2."create snapshot". Wait for snapshot-image to be created.
3. Editing the image via horizon enforces either manually specifying or removing os_hash_algo and os_hash_value

Actual results:
the update image dialog considers the form as incomplete and greys out the 'Update Image' button

Expected results:
These fields, if needed to be present as default image property, should have some default value like 'none' or any default to avoid forcing end user to update them or remove them


Additional info:

- Same issue was reported by the customer earlier and bug https://bugzilla.redhat.com/show_bug.cgi?id=2014558 was opened and marked as fixed in 16.2.1.

Customer env. is updated to 16.2.3 and they still see this issue.- Verified the above steps in one of the local env. with RHOSP16.2.3 and it's reproducible.


Detailed analysis done by customer:

===============================
According to 
https://bugzilla.redhat.com/show_bug.cgi?id=2014558
the fix for this is implemented by
https://review.opendev.org/c/openstack/horizon/+/812009/
specifically
https://review.opendev.org/c/openstack/horizon/+/812009/3/horizon/static/framework/widgets/metadata/tree/tree.service.js
which looks at the metadata-item in question and sets the "required" flag to "false" if the value is '' - defined but empty.


checking the database reveals the following:


MariaDB [glance]> select name,os_hash_algo,os_hash_value from glance.images where name="test-snap-16.2.3";
+------------------+--------------+---------------+
| name             | os_hash_algo | os_hash_value |
+------------------+--------------+---------------+
| test-snap-16.2.3 | NULL         | NULL          |
+------------------+--------------+---------------+
1 row in set (0.000 sec)
so both os_hash_algo and os_hash_value are actually 'NULL'  and not '' - which is due to


MariaDB [glance]> show create table images\G
*************************** 1. row ***************************
       Table: images
Create Table: CREATE TABLE `images` (
  `id` varchar(36) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `size` bigint(20) DEFAULT NULL,
  `status` varchar(30) NOT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime DEFAULT NULL,
  `deleted_at` datetime DEFAULT NULL,
  `deleted` tinyint(1) NOT NULL,
  `disk_format` varchar(20) DEFAULT NULL,
  `container_format` varchar(20) DEFAULT NULL,
  `checksum` varchar(32) DEFAULT NULL,
  `owner` varchar(255) DEFAULT NULL,
  `min_disk` int(11) NOT NULL,
  `min_ram` int(11) NOT NULL,
  `protected` tinyint(1) NOT NULL DEFAULT 0,
  `virtual_size` bigint(20) DEFAULT NULL,
  `visibility` enum('private','public','shared','community') NOT NULL DEFAULT 'shared',
  `os_hidden` tinyint(1) NOT NULL DEFAULT 0,
  `os_hash_algo` varchar(64) DEFAULT NULL,
  `os_hash_value` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `checksum_image_idx` (`checksum`),
  KEY `ix_images_deleted` (`deleted`),
  KEY `owner_image_idx` (`owner`),
  KEY `created_at_image_idx` (`created_at`),
  KEY `updated_at_image_idx` (`updated_at`),
  KEY `visibility_image_idx` (`visibility`),
  KEY `os_hidden_image_idx` (`os_hidden`),
  KEY `os_hash_value_image_idx` (`os_hash_value`),
  CONSTRAINT `CONSTRAINT_2` CHECK (`deleted` in (0,1)),
  CONSTRAINT `CONSTRAINT_3` CHECK (`protected` in (0,1)),
  CONSTRAINT `CONSTRAINT_4` CHECK (`os_hidden` in (0,1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.000 sec)
those actually being defined as "DEFAULT NULL" .


I have taken one of our non-production-regions and modified that javascript as follows:


[root@lictrl90001 js]# diff c422e1a2b230.js.backup c422e1a2b230.js
577c577
< Property.prototype.setValue=function(value){if(value===null){this.value=this.type!=='array'?null:[];return;}
---
> Property.prototype.setValue=function(value){if(value===null){console.log(this.name, this.value);this.value=this.type!=='array'?null:[];return;}
which hooks into the function that handles values that are null - undefined - and logs all the names and values that are treated there.


The result is that I get lines for both os_hash_algo and os_hash_value as name and null as value - and since that function has an early return after handling the exceptions these are not made optional.


This patch here
https://www.alle-irre.de/~hardy/0001-Fix-metadata-update-dialog.patch
will take care of actually fixing the issue by also setting fields where the current value is null to be optional.


I am reasonably certain that it is safe to set all items where the value is null to not be required, but there is a chance that this is different for arrays - I don't have any of those here, I don't know if any of those are ever created and then default to null.


We require a hotfix for that - and that hotfix needs to include the hotfix for https://access.redhat.com/support/cases/#/case/03262257 / https://access.redhat.com/solutions/6960775 as well since that's all the same rpms.


===============

Comment 24 Shravan Kumar Tiwari 2023-02-10 14:26:20 UTC
Hi Tatiana,

Customer applied the same rpm as hotfix in their recently updated 16.2.4 cluster and they are getting following error when trying to click on update image tab.
They do see the fields osh_hash_also and os_hash_value as read only and 'update image' tag is enabled but getting error when clicking so in turn not allowing the image edit.

(The screenshot of the error and other error details present in support case : 03352195)
Error: Forbidden. Insufficient permissions of the requested operation
Error: Unable to edit the image custom properties.

please have a look and let me know what can be done to unblock the customer.

Note: I had verified those hotfix rpms in one of the RHOSP16.2.3 cluster and it was working as expected. but, same steps are failing in 16.2.4.

Comment 32 Cyril Roelandt 2023-02-14 14:29:41 UTC
It seems to me that the fix here is to not ask Glance to update  read-only fields.

Comment 49 errata-xmlrpc 2023-04-26 12:17:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat OpenStack Platform 16.2.5 (Train) bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:1763

Comment 50 Red Hat Bugzilla 2023-09-19 04:29:28 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


Note You need to log in before you can comment on or make changes to this bug.