As written in the design doc (see the parent issue) it was proposed to download the configuration from the scm by the other services.
I propose to create a separated endpoint to provide the ozone configuration. /conf can't be used as it contains all the configuration and we need only the modified configuration.
The easiest way to implement this feature is:
- Create a simple rest endpoint which publishes all the configuration
- Download the configurations to $HADOOP_CONF_DIR/ozone-global.xml during the service startup.
- Add ozone-global.xml as an additional config source (before ozone-site.xml but after ozone-default.xml)
- The download can be optional
With this approach we keep the support of the existing manual configuration (ozone-site.xml has higher priority) but we can download the configuration to a separated file during the startup, which will be loaded.
There is no magic: the configuration file is saved and it's easy to debug what's going on as the OzoneConfiguration is loaded from the $HADOOP_CONF_DIR as before.
Possible follow-up steps:
- Migrate all the other services (recon, s3g) to the new approach. (possible newbie jiras)
- Improve the CLI to define the SCM address. (As of now we use ozone.scm.names)
- Create a service/hostname registration mechanism and autofill some of the configuration based on the topology information.