errose28 commented on PR #38:
URL: https://github.com/apache/ozone-docker/pull/38#issuecomment-2583528483
Ah I was looking at `ozone-latest` (which is an alias for 1.4.0), not
`latest` so I still saw the old files. Side note, we need to move
`ozone-latest` to point to `ozone-1.4.1`. That step may not be present in the
release guide.
Can we simplify this config process? The whole env variable + python script
thing always looked strange to me. IMO the most intuitive way to do this would
be:
- Ozone tarball ships with an empty config like it has now.
- Docker image puts a sensible default config for docker deployments into
the image like it was doing before HDDS-11809
- Using the config baked into the image would still only require the
`docker-compose.yaml` file to start the cluster.
- To override configs in the image, mount a config file as a volume on top
of the existing config file in the image. This will effectively replace it.
- This approach can also be used by all Ozone acceptance tests, so their
config files can be actual `ozone-site.xml` files that are familiar to users
and their compose files can handle the config mounting
To me this makes the quick start aspect much more intuitive, because new
users won't think that the env var approach is some standard way of configuring
Ozone and that the variables are handled by the Ozone process itself. The
downside is that the compose file working without other files OOTB is coupled
to the config shipped with the Ozone image it is using. Since they are managed
in the same repo I feel that this is ok though.
If we do want specific service configurations baked into the
docker-compose.yaml file (SCM/OM service IDs and membership, for example),
passing `-D<key>=<value>` to the service's entrypoint is probably better than
cluster wide variables anyways. This uses a standard Ozone feature to get the
configs to the process while also making it clear which services actually need
the specified config keys.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
