Bug 751474 - Add support for tracking and reporting compliance
Add support for tracking and reporting compliance
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.2
Unspecified Unspecified
high Severity unspecified (vote)
: ---
: JON 3.0.0,RHQ 4.3.0
Assigned To: John Sanda
Mike Foley
:
Depends On: 751846 751912 751913 751914
Blocks: 707225
  Show dependency treegraph
 
Reported: 2011-11-04 16:27 EDT by John Sanda
Modified: 2012-02-07 14:26 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-07 14:23:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Sanda 2011-11-04 16:27:31 EDT
Description of problem:
A resource with a pinned definition that has drift is said to be out of compliance. We currently do not have a way for easily reporting resources that are out of compliance, nor do we have a way for tracking when resources come back into compliance. Coming back into compliance means that there is no longer any drift.

We need to be able to show for each definition whether or not it is in or out of compliance. The drift definitions view should be updated to support this. A flag of some sort should be displayed to indicate whether or not the definition is in or out of compliance.

We also the inventory summary in the reports section to show whether or not resources are out of compliance. Note that if a resource has multiple pinned definitions, only one of those definitions has to have drift for the resource to be out of compliance. All of the resource's pinned definitions must have no drift for the resource to be in compliance.

Lastly we are expanding the meaning of compliance slightly to include definitions that are created with a non-existent base directory. The primary reason for this inclusion is because we need a reporting mechanism (at the resource definition level) to indicate if/when a definition is created with a non-existent base directory. A user could have for example made a typo, or the intended directory may not exist on the target machine. If the base directory is later created then the resource should come back into compliance. Note that extending compliance to include non-existent base directories applies to pinned as well as unpinned definitions.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 John Sanda 2011-11-04 17:48:06 EDT
Added support for viewing compliance in the drift definitions view at the resource level

master branch commit hash:  fa55e1b11afb478de2273ac0a9ff0f649abb4001
release_jon3.x commit hash: cac994d7f026b03df8c8abf3b8209157489af7f7

Still need to add it to the inventory summary report.
Comment 2 John Sanda 2011-11-07 14:57:37 EST
Added support for flagging definitions as out of compliance when they are created with a base directory that does not exist. If and when the base directory is created the definition is updated as being back in compliance.


master commit hash:         efcd91eb5e853e3aaf21d45bf92a966bb460c34d
release_jon3.x commit hash: 34011a3bf7c201f67d33ed345138254b7bab835e
Comment 3 John Sanda 2011-11-07 21:46:13 EST
The three features discussed in the description can for the most part be implemented independent of one another, and they can be tested independently as well. In light of this, I decided to break the work up into three separate bugs so that QE can start looking at it sooner rather than later.

bug 751912
bug 751913
bug 751914
Comment 4 John Sanda 2011-11-11 17:22:32 EST
Once bugs 751912, 751913, 751914 are all verified this bug can be closed.
Comment 5 Mike Foley 2011-11-17 11:21:07 EST
this is an umbrella bug coverin
bug 751912
bug 751913
bug 751914

...they are all verified.
Comment 6 Mike Foley 2012-02-07 14:23:26 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
Comment 7 Mike Foley 2012-02-07 14:26:00 EST
marking VERIFIED JON 3 bugs to CLOSED/CURRENTRELEASE

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