Bug 1130732 - FreeSpaceCriticalLowInGB could be set to unreasonably large numbers,the result is that almost every action is blocked with CNA
Summary: FreeSpaceCriticalLowInGB could be set to unreasonably large numbers,the resul...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-config
Version: 3.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.5.0
Assignee: Allon Mureinik
QA Contact: Pavel Stehlik
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-17 07:31 UTC by Ori Gofen
Modified: 2016-02-10 19:19 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-18 20:27:34 UTC
oVirt Team: Storage


Attachments (Terms of Use)
image (159.22 KB, image/png)
2014-08-17 07:31 UTC, Ori Gofen
no flags Details

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.


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