Bug 1814214 - default and non-default storage quota incorrect percentage
Summary: default and non-default storage quota incorrect percentage
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin
Version: 4.3.8.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Lucia Jelinkova
QA Contact: Lucie Leistnerova
URL:
Whiteboard:
Depends On:
Blocks: 1861745
TreeView+ depends on / blocked
 
Reported: 2020-03-17 11:50 UTC by Marko Vrgotic
Modified: 2021-08-30 11:45 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
: 1861745 (view as bug list)
Environment:
Last Closed: 2021-08-30 11:45:16 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.5?


Attachments (Terms of Use)
percentage vs actual usage (225.98 KB, application/zip)
2020-03-17 11:50 UTC, Marko Vrgotic
no flags Details

Description Marko Vrgotic 2020-03-17 11:50:34 UTC
Created attachment 1670786 [details]
percentage vs actual usage

Description of problem:

Incorrect storage quota usage percentage level, eventually ending up to 0% or Unlimited.

The problem is that it does not represents actual usage with certainty, but rather fluctuating between 0%, actual usage and Unlimited. With some of my data centers, I initially saw it working, then it moved to 0% or Unlimited and it stays like that. Is there a trigger that tells the engine you need to calculate, or if it can be configurable, I do not know, documentation is not very detailed on this part.

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

ovirt-engine-4.3.8.2
ovirt-engine-4.3.5.4

How reproducible:
60% as I have multiple data centers with quotas

Steps to Reproduce:
1. set to Enforced / create storage quota / add consumer(s) 
2. assign this quota to all existing VMs and related images
3. if present, assing to templates as well

Actual results:
Storage Quota percentage shows 0% or Unlimited

Expected results:
Storage quota percentage reflecting actual usage

Additional info:
Check the screenshots attached.
SanJose - storage quota percentage vs storage quota actual utilization
Hilversum - same thing

Comment 1 RHEL Program Management 2020-03-17 12:34:12 UTC
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

Comment 2 Marko Vrgotic 2020-03-24 08:24:23 UTC
Hi RedHat,

Not sure if the above was a question to me, but I am not reporting Documentation bug but actual software bug.

If you need me to provide more data, logs, conf files, I have three platforms deployed, all having same issue.

Marko Vrgotic

Comment 3 Marko Vrgotic 2020-04-06 07:20:40 UTC
Dear RedHat and oVirt,

Considering this COVID-19 situation, I hope you are all doing well and staying healthy.

It has been more than two weeks since I reported this issue. So far I have not received a single update or request, and the issue is still registered as NEW. 

Considering this is one out of three issues regarding oVirt quotas, that I reported, in one day, not getting any update leads me to assumptions:

- I am doing something fundamentally wrong with oVirt Quotas implementation
- There is something fundamentally wrong with oVirt Quotas implementation, from the software side.
- something else…

In any case, I would highly appreciate it if you can find time to look into these issues so we can make progress.

Once again, I am seeing this problem on all three deployed platforms, both in Staging and Production.

Kindly awaiting your reply.

Marko Vrgotic
ActiveVideo

Comment 4 Marko Vrgotic 2020-07-14 14:51:05 UTC
Dear all,

Is this still targeted for 4.5?
If any additional information is needed, just let me know.

Kindly awaiting your reply.

Marko

Comment 5 Arik 2020-07-30 07:55:42 UTC
Incorrect computation on the client side?

Comment 6 Lucia Jelinkova 2020-08-26 13:13:27 UTC
The reason why the values are different on the Quota list page and on the Quota detail page is, that the values on the first one are taken from the Quota cache and the values on the latter one are taken from the database. Can you think of anything that could cause the cached value to be incorrect? Any failed storage operations for example? Might it be somehow related to the following issue caused by the failed disk copy?

https://bugzilla.redhat.com/show_bug.cgi?id=1872602

Comment 7 Marko Vrgotic 2021-03-29 08:09:48 UTC
Hi Lucia,

Apologies for late late reply, but I am going to look into it in next few days and report back.

Comment 8 Arik 2021-08-30 11:45:16 UTC
We provided a fix to something that might explain this.
It might happen due to a different reason but we have not enough information to tell.


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