Bug 1141982

Summary: Configurations of 2 consecutive deployments get mixed up
Product: [JBoss] JBoss Operations Network Reporter: Lukas Krejci <lkrejci>
Component: Provisioning, UIAssignee: Lukas Krejci <lkrejci>
Status: CLOSED CURRENTRELEASE QA Contact: Armine Hovsepyan <ahovsepy>
Severity: high Docs Contact:
Priority: unspecified    
Version: JON 3.3.0CC: ahovsepy, mfoley
Target Milestone: ER04   
Target Release: JON 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-11 14:04:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1069547    
Attachments:
Description Flags
input_old_value
none
input_same_destination
none
input_new_value
none
input_old_version
none
patchId
none
patchId2
none
patch6.2.2
none
patch_cli.log none

Description Lukas Krejci 2014-09-15 22:44:00 UTC 
Description of problem:
When deploying 2 different bundle versions to a single destination, each of the bundle versions having different configuration definition, the resulting default configuration for the second deployment contains default values of properties defined in the FIRST deployment.

Note that this is an UI issue.

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

How reproducible:
always

Steps to Reproduce:
1. create bundle version with deploy.xml containing an input property "input", required, with some default value (can be readonly but doesn't have to)
2. create another bundle version with the deploy.xml containing the following changes:
* bump the bundle version (so that it is deployable on top of the first bundle)
* change the default value of the "input" property
3. Upload the second bundle version
4. Deploy the second bundle version

Actual results:
The "input" property will have a value coming from the first deployment, not the default value provided by the bundle descriptor.

Expected results:
The descriptor should be the authoritative source of data

Additional info:
It is actually debatable what the correct behavior should be. One could argue that it is more likely for the corresponding properties to have the same values across the deployments.

The usecase where this assumption fails would be the readonly properties in the configs - these wouldn't be updatable by the user but could be used to convey some information from the server-side bundle plugin (that creates the config definitions (and thus also the default values)) to the agent-side bundle handler.

This usecase is actually being used by JON's impl of EAP patching.
Comment 1 Lukas Krejci 2014-09-15 22:45:30 UTC 
Basing the severity, target version and target milestone on BZ 1069547 which is blocked by this issue.
Comment 2 Lukas Krejci 2014-09-22 17:05:15 UTC 
master: 8ddc6ca38e45b6312fb7d903a5f9eef50cf068bb
release/jon3.3.x: dd19935f47acf2a4da8c81ec2f8e9f2f0d8d45eb
Author: Lukas Krejci <lkrejci>
Date:   Wed Sep 17 21:24:53 2014 +0200

    [BZ 1141982] Readonly required props with defaults forced to same values
    during bundle deployment.
    
    In the case of new resource creation where the user has the
    ability to enter an initial value for a readonly property. This is
    not true with bundle deployment because the configuration object is
    populated with the default values straight away. This is to make it
    possible for the server-side bundle plugin to pass on some
    information to the agent-side bundle handler.
    
    This fix ensures that an update of such readonly property is not
    possible either through UI or remote API.
    
    In remote API we simply check the supplied deployment configuration
    more rigorously, disallowing changes of any readonly properties from
    the default values provided by the deployment configuration definition.
    
    The UI had a clever logic of reusing configuration properties used
    with the currently live deployment (if any). This approach generally
    worked but was also updating readonly properties with the values
    coming from the live deployment which is a wrong thing to do if we
    understand the readonly props as a way of defining additional
    metadata about the bundle version generated by the server-side plugin.
    These should always be relevant to the bundle version being deployed
    and not taken over from a deployment of some previous bundle version.
Comment 3 Lukas Krejci 2014-09-22 20:46:20 UTC 
The release branch commit hash is this:
def8112715dc27123d6e3534c4be7bf255f05ce9
Comment 4 Simeon Pinder 2014-10-01 21:33:14 UTC 
Moving to ON_QA as available for test with build:
https://brewweb.devel.redhat.com/buildinfo?buildID=388959
Comment 6 Armine Hovsepyan 2014-10-14 08:23:30 UTC 
deploying new version of the bundle with changed input on top of old destination still uses the old input values. Screen-shots attached.
Comment 7 Armine Hovsepyan 2014-10-14 08:24:01 UTC 
Created attachment 946726 [details]
input_old_value
Comment 8 Armine Hovsepyan 2014-10-14 08:24:54 UTC 
Created attachment 946727 [details]
input_same_destination
Comment 9 Armine Hovsepyan 2014-10-14 08:25:41 UTC 
Created attachment 946728 [details]
input_new_value
Comment 10 Armine Hovsepyan 2014-10-14 08:26:10 UTC 
Created attachment 946730 [details]
input_old_version
Comment 11 Lukas Krejci 2014-10-14 09:38:15 UTC 
The additional info of the bug description contains a note that it is debatable whether the proposed behavior makes sense for writable properties.

The commit message in comment #2 then explicitly states that in the end the proposed behavior has been changed for readonly required properties only.

As such, the following should be true when creating a new deployment on a destination:

1) writable properties should inherit values from the live deployment
2) readonly required properties should always have their default values defined in the descriptor of the bundle version being deployed.

Also additionally, the behavior wrt readonly required props should be tested when using the CLI to do the bundle deployment.
Comment 12 Armine Hovsepyan 2014-10-15 12:37:21 UTC 
verified in JON 3.3 ER04
screen-shot for GUI and log from cli deployments attached
Comment 13 Armine Hovsepyan 2014-10-15 12:38:26 UTC 
Created attachment 947208 [details]
patchId
Comment 14 Armine Hovsepyan 2014-10-15 12:38:45 UTC 
Created attachment 947209 [details]
patchId2
Comment 15 Armine Hovsepyan 2014-10-15 12:39:08 UTC 
Created attachment 947210 [details]
patch6.2.2
Comment 16 Armine Hovsepyan 2014-10-15 12:39:26 UTC 
Created attachment 947211 [details]
patch_cli.log