Bug 846272

Summary:	PRD32 - [rhevm-dwh] - RFE - Add storage domains status in the History DB
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	David Botzer <dbotzer>
Component:	ovirt-engine-dwh	Assignee:	Yaniv Lavi <ylavi>
Status:	CLOSED ERRATA	QA Contact:	David Botzer <dbotzer>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.1.0	CC:	acathrow, bazulay, dyasny, iheim, pstehlik, Rhev-m-bugs, ykaul, zdover
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	3.2.0	Flags:	dyasny: Triaged+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
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 21:56:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	891070
Bug Blocks:	915537

Description David Botzer 2012-08-07 10:27:14 UTC

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 11:39:20 UTC

This is for data domains only

Comment 2 Dan Yasny 2012-12-19 13:15:19 UTC

(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 14:01:30 UTC

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 14:04:21 UTC

(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 14:09:03 UTC

(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 10:08:45 UTC

(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 11:29:11 UTC

#2 seems the sanest to me

Comment 9 Yaniv Lavi 2013-01-01 14:53:50 UTC

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 16:05:15 UTC

(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 12:22:37 UTC

Submitted patches:
engine side - http://gerrit.ovirt.org/10564
dwh side - http://gerrit.ovirt.org/10565




Yaniv

Comment 13 David Botzer 2013-02-18 16:16:13 UTC

Found in Clean SF7 installation,
Cannot find when upgrading from SF prior to SF7 to SF7

Comment 14 David Botzer 2013-03-17 09:48:54 UTC

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 21:56:21 UTC

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