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):
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
The "input" property will have a value coming from the first deployment, not the default value provided by the bundle descriptor.
The descriptor should be the authoritative source of data
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.
Author: Lukas Krejci <firstname.lastname@example.org>
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:
Moving to ON_QA as available for test with build:
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]
Created attachment 946727 [details]
Created attachment 946728 [details]
Created attachment 946730 [details]
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]
Created attachment 947209 [details]
Created attachment 947210 [details]
Created attachment 947211 [details]