Bug 1788117 - RAM and CPU fields in Edit flavor dialog
Summary: RAM and CPU fields in Edit flavor dialog
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.5.0
Assignee: Filip Krepinsky
QA Contact: Nelly Credi
URL:
Whiteboard:
Depends On:
Blocks: 1807142
TreeView+ depends on / blocked
 
Reported: 2020-01-06 13:23 UTC by Radim Hrazdil
Modified: 2020-05-04 11:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1807142 (view as bug list)
Environment:
Last Closed: 2020-05-04 11:22:02 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 4353 0 None closed Bug 1788117: fix CPU and RAM editing in Flavor dialog 2020-04-22 09:17:10 UTC
Red Hat Product Errata RHBA-2020:0581 0 None None None 2020-05-04 11:22:40 UTC

Description Radim Hrazdil 2020-01-06 13:23:54 UTC
Description of problem:
When user attempts to edit Custom flavor via 'Edit Flavor' dialog in VM Overview page, the value in CPU/RAM fields cannot be fully deleted. It always contains at least value 1.

It means that when a user wants to change CPU count from 1 (which is default)
 to 2, it's necessary to first append number 2 (meaning now the field contains value 12) and then delete the number 1. Same goes to the RAM field.

Version-Release number of selected component (if applicable):
OCP 4.3

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Tomas Jelinek 2020-01-15 11:45:44 UTC
at one hand it is not really incorrect since the validation does not allow this field to be empty (e.g. if you pressed a letter it would also not print it). On the other hand, the VM wizard does allow in those fields empty strings. So we should decide which one is correct and unify.
@Matt: WDYT?

Comment 2 Matt 2020-01-15 14:52:23 UTC
I agree this feels a bit strange. Can we not validate the fields when they are empty when they attempt to save/move forward and require values?

Comment 3 Tomas Jelinek 2020-01-15 15:09:35 UTC
(In reply to Matt from comment #2)
> I agree this feels a bit strange. Can we not validate the fields when they
> are empty when they attempt to save/move forward and require values?

yes, this is how we do it in the VM wizard. OK, so we should do the same here as well, ack.

Comment 6 Guohua Ouyang 2020-02-20 08:22:37 UTC
It's still cannot be fully deleted, but user can draw the mouse over "1", then it has a shadow on the number, then can replace with any other value.
As the design it is, move the bug to verified.

Comment 7 Filip Krepinsky 2020-02-25 17:12:40 UTC
This one landed only in 4.5, 4.4 is still broken

Comment 9 errata-xmlrpc 2020-05-04 11:22:02 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, 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-2020:0581


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