This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 749419 - Do not let a definition pinned to a template be re-pinned to a different snapshot
Do not let a definition pinned to a template be re-pinned to a different snap...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.1
Unspecified Unspecified
high Severity unspecified (vote)
: ---
: ---
Assigned To: John Sanda
Mike Foley
:
Depends On:
Blocks: 707225
  Show dependency treegraph
 
Reported: 2011-10-26 20:56 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:26:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Sanda 2011-10-26 20:56:34 EDT
Description of problem:
When a drift definition is pinned to a template, the snapshot to which the definition is pinned is determined by the template. When a definition is created from a pinned template, the definition remains attached to the template and pinned to the template snapshot for the life time of the definition.

Currently you can go to the snapshot view for a definition created from a pinned template and re-pin the definition against some other snapshot. This should be prevented in the UI (as well as in the remote APIs).

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


How reproducible:
always

Steps to Reproduce:
1. Create an unpinned template
2. Create a definition from the template
3. Wait for snapshot zero to be reported
4. Pin snapshot zero to the template. Note that this makes both the template and the definition pinned. 
5. Now make a change to one of the files that are under drift detection.
6. Wait for snapshot one to be reported.
7. Go to the snapshot view for snapshot one.
8. Click the 'Pin to Definition' button in the footer. 
  
Actual results:
What was snapshot one will become the new snapshot zero.

Expected results:
You should not be able to perform the 'Pin to Definition' action which is a resource-level pinning. The button should be disabled and/or an error message of some sorts should be displayed that explains pinning to a definition is not allowed for a definition created from a pinned template.


Additional info:
Comment 1 John Sanda 2011-11-14 09:19:58 EST
I have made changes so that the "Pin to Definition" button is disabled in the snapshot view. The "Pin to Template" button however is not disabled. The reason for this is as follows.

Pinning a snapshop to a template only effects the definition when the template is the one from which the definition was created. If you pin to a new template or some other existing template, the definition (to which the snapshot belongs) remains unmodified.
    
We do want to allow "repinning" particularly to support planned changes. Suppose you have a pinned template and pinned definition for an EAP server. As part of a planned change, you deploy a new or updated application to the EAP server. Drift monitoring is set up for the EAP server. A new snapshot is generated after the application is deployed, and you will want to repin the template to that new snapshot.

master commit hash: 8777734dc997d9c499479eaaee692d57e1e31766
release_jon3.x commit hash: ffe008e5e343d594de53bffde293119ecb1fb224
Comment 2 Mike Foley 2011-11-14 11:14:04 EST
verification blocked ...

https://bugzilla.redhat.com/show_bug.cgi?id=753827
Comment 3 John Sanda 2011-11-14 12:11:41 EST
You can still verify this bug. Just use unique names for the templates.
Comment 4 Mike Foley 2012-02-07 14:26:40 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

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