Bug 1130732

Summary: FreeSpaceCriticalLowInGB could be set to unreasonably large numbers,the result is that almost every action is blocked with CNA
Product: [Retired] oVirt Reporter: Ori Gofen <ogofen>
Component: ovirt-engine-configAssignee: Allon Mureinik <amureini>
Status: CLOSED NOTABUG QA Contact: Pavel Stehlik <pstehlik>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.5CC: acanan, acathrow, amureini, bugs, ecohen, gklein, iheim, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-18 20:27:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
image none

Description Ori Gofen 2014-08-17 07:31:20 UTC 
Created attachment 927419 [details]
image

Description of problem:
when setting FreeSpaceCriticalLowInGB to a number that is larger than the amount of space at the storage domain,engine blocks all actions on domains with CNA except editing actions.

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

How reproducible:
100%

Steps to Reproduce:
1.run 'engine-config -s FreeSpaceCriticalLowInGB=2147483647'
2.restart engine (service ovrit-engine restart)
3.try to create a disk,run vm,create template

Actual results:
almost all actions are blocked

Expected results:
the threshold should be correlated with domain's size

Additional info:
Comment 1 Allon Mureinik 2014-08-18 20:27:34 UTC 
Any number you'd want to cap it with will ultimately fail some customer with a ridiculously large storage array.
We don't nanny the user.
Comment 2 Ori Gofen 2014-08-18 22:04:15 UTC 
That's why I wrote at the expected result: "the threshold should be correlated with domain's size",should be so easy to implement and when considering the enormous damage it can save,I really don't understand this decision.

What are we saying here?
That the fact that we have a seemingly harmless flag which most users are not even familiar with ,and can cause the entire engine to be blocked with CDA (security breach?) 
and we are ok with that?
I say we should choose the alternative and spend five minutes to set threshold_max =< 50% domain's_size
Comment 3 Allon Mureinik 2014-08-19 10:59:17 UTC 
(In reply to Ori from comment #2)
> That's why I wrote at the expected result: "the threshold should be
> correlated with domain's size", should be so easy to implement
The point isn't the ease of implementation, it's it's (lack of) correctness.

> and when
> considering the enormous damage it can save,
None.
Exactly 0 "damage".
If a user needs this kind of reliance (probably because of some underlying storage array consideration), we should allow it.
We do not nanny the user.


> That the fact that we have a seemingly harmless flag which most users are
> not even familiar with 
A user who isn't familiar with a flag won't go ahead and play with it.

> ,and can cause the entire engine to be blocked with
> CDA (security breach?) 
You need access to the machine running oVirt Engine in order to do this. There's no security breach here.