Bug 1141982 - Configurations of 2 consecutive deployments get mixed up
Summary: Configurations of 2 consecutive deployments get mixed up
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Provisioning, UI
Version: JON 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER04
: JON 3.3.0
Assignee: Lukas Krejci
QA Contact: Armine Hovsepyan
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: JON3-10, PRODMGT-544
TreeView+ depends on / blocked
 
Reported: 2014-09-15 22:44 UTC by Lukas Krejci
Modified: 2015-09-03 00:03 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-12-11 14:04:27 UTC


Attachments (Terms of Use)
input_old_value (112.86 KB, image/png)
2014-10-14 08:24 UTC, Armine Hovsepyan
no flags Details
input_same_destination (112.65 KB, image/png)
2014-10-14 08:24 UTC, Armine Hovsepyan
no flags Details
input_new_value (112.86 KB, image/png)
2014-10-14 08:25 UTC, Armine Hovsepyan
no flags Details
input_old_version (146.44 KB, image/png)
2014-10-14 08:26 UTC, Armine Hovsepyan
no flags Details
patchId (84.30 KB, image/png)
2014-10-15 12:38 UTC, Armine Hovsepyan
no flags Details
patchId2 (83.04 KB, image/png)
2014-10-15 12:38 UTC, Armine Hovsepyan
no flags Details
patch6.2.2 (94.58 KB, image/png)
2014-10-15 12:39 UTC, Armine Hovsepyan
no flags Details
patch_cli.log (5.36 KB, text/plain)
2014-10-15 12:39 UTC, Armine Hovsepyan
no flags Details

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@redhat.com>
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


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