Bug 846272 - PRD32 - [rhevm-dwh] - RFE - Add storage domains status in the History DB
PRD32 - [rhevm-dwh] - RFE - Add storage domains status in the History DB
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-dwh (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.2.0
Assigned To: Yaniv Lavi
David Botzer
infra
: FutureFeature
Depends On: 891070
Blocks: 915537
  Show dependency treegraph
 
Reported: 2012-08-07 06:27 EDT by David Botzer
Modified: 2016-02-10 14:31 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
The status field is now used in the history database to display the history of Storage Domains' statuses.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-10 17:56:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dyasny: Triaged+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 10564 None None None Never

  None (edit)
Description David Botzer 2012-08-07 06:27:14 EDT
Description of problem:
Add storage domains status info in the history DB :
  - in v3_1_storage_domain_samples/hourly/daily_history_view
  - v3_1_enum_translator_view

Version-Release number of selected component (if applicable):
3.1/si13.1

How reproducible:
always

Steps to Reproduce:
1.Storage Domains status is kept in storage_pool_iso_map table 
2.The status field should be used in the history DB
  
Actual results:
No way to display info on Storage Domains status in Reports

Expected results:
The status field should be used in the history DB to display history for Storage Domains status

Additional info:
Comment 1 Barak 2012-10-28 07:39:20 EDT
This is for data domains only
Comment 2 Dan Yasny 2012-12-19 08:15:19 EST
(In reply to comment #1)
> This is for data domains only

why? can you explain, because all SD types have a status that can be saved in history
Comment 3 Barak 2012-12-19 09:01:30 EST
ISO domains are different in several aspects:
- Can be shared among DCs
- They are only ISO domain
- The rate of changes is lower

So theoretically speaking an ISO domain can be active for one DC and problematic for a different DC.

Yaniv please take a look at it and provide info about complexity of solution.
Comment 4 Barak 2012-12-19 09:04:21 EST
(In reply to comment #3)
> ISO domains are different in several aspects:
> - Can be shared among DCs
> - They are only ISO domain

                ^ NFS ^

> - The rate of changes is lower
> 
> So theoretically speaking an ISO domain can be active for one DC and
> problematic for a different DC.
> 
> Yaniv please take a look at it and provide info about complexity of solution.
Comment 5 Dan Yasny 2012-12-19 09:09:03 EST
(In reply to comment #3)
> ISO domains are different in several aspects:
> - Can be shared among DCs
> - They are only ISO domain
> - The rate of changes is lower
> 
> So theoretically speaking an ISO domain can be active for one DC and
> problematic for a different DC.
> 

OK, this makes sense, if we report in the context of a single DC. 

> Yaniv please take a look at it and provide info about complexity of solution.

Yaniv?
Comment 6 Yaniv Lavi 2012-12-23 05:08:45 EST
(In reply to comment #5)
> (In reply to comment #3)
> > ISO domains are different in several aspects:
> > - Can be shared among DCs
> > - They are only ISO domain
> > - The rate of changes is lower
> > 
> > So theoretically speaking an ISO domain can be active for one DC and
> > problematic for a different DC.
> > 
> 
> OK, this makes sense, if we report in the context of a single DC. 
> 
> > Yaniv please take a look at it and provide info about complexity of solution.
> 
> Yaniv?

We have three options:
1. match the backend method of abusing the map table to hold the status as well and creating a way to measure the amount of time in each status.
2. separate to a new table in the regular way we work (samples\hourly\daily) that will contain storage domain id, datacenter id, status and time in status.
3. make the map table become a sampling table (least preferable).


Dan, What do you think is best?
Comment 7 Dan Yasny 2012-12-24 06:29:11 EST
#2 seems the sanest to me
Comment 9 Yaniv Lavi 2013-01-01 09:53:50 EST
In later talks on this feature we decided to use the shared storage domain status function to add status to storage domain statistics. After exploring in this direction I found that the function is problematic and using it may induce bugs (Added BZ #891070). 

The options are to:
- Wait for this bug I added as dependent to be resolved and only then add support for dwh collection.
- Add this feature using the current function even due it's currently not working properly and fix the dwh view as well, when this is fixed.
- Go with the previous option and separate to a new tables in the regular way we work (samples\hourly\daily) that will contain storage domain id, datacenter id, status and time in status.


Miki\Dann, what do you think?




Yaniv
Comment 10 Dan Yasny 2013-01-01 11:05:15 EST
(In reply to comment #9)
> - Go with the previous option and separate to a new tables in the regular
> way we work (samples\hourly\daily) that will contain storage domain id,
> datacenter id, status and time in status.

this, and once 891070 is fixed, move on to the better option
Comment 11 Yaniv Lavi 2013-01-02 07:22:37 EST
Submitted patches:
engine side - http://gerrit.ovirt.org/10564
dwh side - http://gerrit.ovirt.org/10565




Yaniv
Comment 13 David Botzer 2013-02-18 11:16:13 EST
Found in Clean SF7 installation,
Cannot find when upgrading from SF prior to SF7 to SF7
Comment 14 David Botzer 2013-03-17 05:48:54 EDT
Fixed, 3.2/SF9-SF10 upgrade
Fixed, 3.2/Clean-SF10
Status is available in 
v3_2_statistics_storage_domains_resources_usage_samples/hourly/daily
And aggregated correctly
Fixed, 3.2/SF9-SF10 upgrade
Fixed, 3.2/Clean-SF10
Comment 15 errata-xmlrpc 2013-06-10 17:56:21 EDT
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.

http://rhn.redhat.com/errata/RHEA-2013-0926.html

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