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.
Basing the severity, target version and target milestone on BZ 1069547 which is blocked by this issue.
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.
The release branch commit hash is this: def8112715dc27123d6e3534c4be7bf255f05ce9
Moving to ON_QA as available for test with build: https://brewweb.devel.redhat.com/buildinfo?buildID=388959
deploying new version of the bundle with changed input on top of old destination still uses the old input values. Screen-shots attached.
Created attachment 946726 [details] input_old_value
Created attachment 946727 [details] input_same_destination
Created attachment 946728 [details] input_new_value
Created attachment 946730 [details] input_old_version
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.
verified in JON 3.3 ER04 screen-shot for GUI and log from cli deployments attached
Created attachment 947208 [details] patchId
Created attachment 947209 [details] patchId2
Created attachment 947210 [details] patch6.2.2
Created attachment 947211 [details] patch_cli.log