HiveMQ Edge Mutable and Immutable Configuration Options
HiveMQ Edge is designed to be run in both container and standalone environments.
When run in containers, the configuration is considered immutable since changes
to the underlying config.xml can be lost during some scaling/deployment events.
For this reason, configuration enables the user to selectively decide whether to allow API or UI interactions to update the config.xml.
| Property Name | Description | Format |
|---|---|---|
|
When enabled, the current state of the configuration xml file can be exported via the API endpoint |
|
|
When enabled, changes to bridges, protocol adapters, data combiners, asset mappers, UNS, and Pulse settings are written to the config.xml file. The default is |
|
With allow-mutable-configuration set to false, the REST API and the UI still accept changes and apply them to the running node. Only the write to config.xml is skipped.
To reject configuration changes through the REST API and the UI altogether, disable configuration writing. Start HiveMQ Edge with the Java option hivemq.config.writeable=false or the environment variable HIVEMQ_CONFIG_WRITEABLE=false.
Every request that would modify the configuration is then answered with the HTTP status 403. The response carries the message Modifying the config via the API has been disabled.
The Helm chart sets this variable, because the configuration of a container is managed through Helm.
For how HiveMQ Edge writes the file, keeps backups, and reloads changes, see Configuration File Writes and Configuration Hot Reload.
Mutable Configuration (default)
Mutable configuration is designed for use in standalone deployment modes. Mutable configuration files are updated by changes to the API or user interface. Configuration changes are reflected across process restart.
<dynamic-configuration>
<allow-configuration-export>false</allow-configuration-export>
<allow-mutable-configuration>true</allow-mutable-configuration>
</dynamic-configuration>Immutable Configuration
Immutable configuration is designed for use in container deployment and orchestration modes. Immutable configuration files are NOT written during interactions with the API or user interface. Instead, state changes are reflected ephemerally in the runtime, a restart event reverting to the initial configuration. Running in this mode allows the ephemeral state to be exported via API or user interface. Immutable configuration files can be updated with an offline process.
<dynamic-configuration>
<allow-configuration-export>true</allow-configuration-export>
<allow-mutable-configuration>false</allow-mutable-configuration>
</dynamic-configuration>