Project

General

Profile

Actions
Copy link

Bug #9418

open

No validation on input storage size compute profile

Added by Bryan Kearney almost 10 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Compute resources
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
1193306
Pull request:
Fixed in Releases:
Found in Releases:
Red Hat JIRA:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1193306
Description of problem:
The "Size (G)" field has no validation. You can enter anything you like and it will be stored. I made the mistake to specify 8GB and not 8G. It accepted it, but it failed to provision. IT took quit some time to figure out what was wrong.

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

How reproducible:
Enter anything you like in compute profile -> Storage -> Size.

Steps to Reproduce:
1.
2.
3.

Actual results:
Everything is accepted

Expected results:
Only positive integers should be accepted (the G in the field description "Size (G) already has the unit).

Additional info:

Actions
Copy link
 #1

Updated by Dominic Cleal almost 10 years ago

  • Category set to Compute resources
  • Status changed from New to Need more information
  • Assignee deleted (Ohad Levy)

Which compute resource is this?

Actions
Copy link
 #2

Updated by Bryan Kearney almost 10 years ago

I am checking with the reporter

Actions
Copy link
 #3

Updated by Tomer Brisker almost 9 years ago

  • Category changed from Compute resources to Compute resources - libvirt
  • Status changed from Need more information to New

This is still present in libvirt resource.

Actions
Copy link
 #4

Updated by Marek Hulán over 8 years ago

  • Category changed from Compute resources - libvirt to Compute resources
  • Target version set to 115

Same thing for oVirt (and probably others) and not only compute profiles but also in host form. The reason is probably the fact that we don't have normal model attribute for that but we serialize volume_attributes as a hash. We should create a non-persistent model for volume and each compute resource should provide mapping methods.

Actions
Copy link
 #5

Updated by Lukáš Hellebrandt over 3 years ago

  • Triaged set to No

I checked with RHEV and can confirm this is indeed reproducible on Sat 6.9.
I can fill whatever value and it's accepted. If it's just a string of letters, it's then shown in WebUI as 0, if it's a string starting with number, that number is shown in WebUI. However, using Hammer, I can see the value is saved as I entered it, e.g.:

# hammer compute-profile info --id 4
Id:                 4
Name:               testcp
Created at:         2021/04/30 13:41:33
Updated at:         2021/04/30 13:41:33
Compute attributes: 
 1) Id:               1
    Name:             1 Cores and 1 GB memory
    Compute Resource: testrhev
    VM attributes:    {"cluster"=>"<uuid>", "template"=>"", "instance_type"=>"", "cores"=>"1", "sockets"=>"1", "memory"=>"1073741824", "ha"=>"0", "display"=>{"type"=>"vnc", "keyboard_layout"=>"en-us"}, "volumes_attributes"=>{"0"=>{"size_gb"=>"5", "storage_domain"=>"<uuid>", "id"=>"", "preallocate"=>"0", "wipe_after_delete"=>"0", "interface"=>"virtio_scsi"}, "1"=>{"size_gb"=>"0", "storage_domain"=>"<uuid>", "id"=>"", "preallocate"=>"0", "wipe_after_delete"=>"0", "interface"=>"virtio_scsi"}, "<id>"=>{"size_gb"=>"a 4 f", "storage_domain"=>"<uuid>", "id"=>"", "preallocate"=>"0", "wipe_after_delete"=>"0", "interface"=>"virtio_scsi"}, "<id>"=>{"size_gb"=>"4 h", "storage_domain"=>"<uuid>, "id"=>"", "preallocate"=>"0", "wipe_after_delete"=>"0", "interface"=>"virtio_scsi"}}}
Actions
Copy link

Also available in: Atom PDF