Instead of using bootstrap scripts for config.properties management, we could use a more user-friendly approach involving environment variables defined in the Compose YAML. Something like:
We'd merge these together based on the presence of configured properties in whatever modules the user wants to provision, then either run an automated script inside the Trino container or mount the collection of properties as a cohesive config.properties file to the container.
We'd want to keep the existing bootstrap functionality around while simultaneously decoupling it from managing this config file.
Remove CLI support for CONFIG and JVM_CONFIG environment variables (see: readme). This is messy and buggy in the first place, and by implementing the 1st request above, there would be little to no need to support these variables.
A few things could be touched up in Minitrino:
config.properties
management, we could use a more user-friendly approach involving environment variables defined in the Compose YAML. Something like:We'd merge these together based on the presence of configured properties in whatever modules the user wants to provision, then either run an automated script inside the Trino container or mount the collection of properties as a cohesive
config.properties
file to the container.We'd want to keep the existing bootstrap functionality around while simultaneously decoupling it from managing this config file.
CONFIG
andJVM_CONFIG
environment variables (see: readme). This is messy and buggy in the first place, and by implementing the 1st request above, there would be little to no need to support these variables.