Red Hat Bugzilla – Bug 749419
Do not let a definition pinned to a template be re-pinned to a different snapshot
Last modified: 2012-02-07 14:26:40 EST
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):
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.
What was snapshot one will become the new snapshot zero.
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.
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
verification blocked ...
You can still verify this bug. Just use unique names for the templates.
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE