THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Where should the property be added?
Identify the service version that the property is valid for. Ensure that the version is already defined in common-services. If not, then add a new version to the common-service. Do not add config properties directly in the stack versions unless the config property is only valid for a specific stack (e.g. HDP-2.4)
...
Note: It is not typical to just remove config properties from a released stack definition. If you absolutely must then ensure that there is corresponding Ambari upgrade code to remove the config property as well.
What should the property value be
Within the stack definition only a default value can be provided. There are several choices:
- The default value may be fine (very typical)
- The default value may be modified for specific deployments using stack advisor (default is not optimal) - E.g. https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py#L80 oozie_admin_users must include the
...
What should happen on Ambari upgrade
...
- falcon service user if falcon exists.
- The default value must be modified (typically properties with localhost or host list) - E.g. https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/resources/stacks/HDP/2.5/services/stack_advisor.py#L496 ATLAS rest address, atlas.rest.address, must be constructed based on where the ATLAS server is installed.
What should happen on Ambari upgrade
The typical behavior is that Ambari upgrade must not modify stack configurations. It is ensured by specifying <on-ambari-upgrade add="false"/> to the config property. Due to historical reasons this is not the default behavior. Earlier versions of Ambari added any missing properties on upgrade. So several existing python scripts assume the existence of the properties.
So unless absolutely required, do not specify a config property to be added by default during Ambari upgrade.
If its needed that a property must be added/updated during Ambari upgrade, there are two choices:
- Specify <on-ambari-upgrade add="true"/> and if the property does not exist in the configurations, it will be added with the default value specified
- Explicitly add config property through upgrade catalog. This is needed if appropriate value must be calculated based on the cluster details. E.g. https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog240.java#L2928 set HBase, hbase.coprocessor.master.classes, to appropriate values based on if Kerberos/Ranger is enabled.
What should happen on Stack upgrade
In contrast, Stack upgrade is a good time to update configs as needed. During stack upgrade all services go through restarts so new config values can easily take effect. By default, stack upgrade will add all new config properties that are missing in the stored configs. In addition, conditional update or deletion of config properties can be achieved through custom declarartive upgrade packs. E.g. https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/config-upgrade.xml#L97 deletes a property, https://github.com/apache/ambari/blob/branch-2.4/ambari-server/src/main/resources/stacks/HDP/2.4/upgrades/config-upgrade.xml#L120 modifies the value.
Display characteristics of the config property
...