Open rdsarvar opened 3 weeks ago
We currently have it all in one to keep it simple. Once the airlift refactor is in we plan to work with Trino and airlift projects to figure out good approach. Our need is kinda different since we use yaml for nested configs quite a bit and Trino/airlift currently dont (yet). So maybe we do something like
We can discuss more in the next sync for starters. Also fyi and for sanity check @willmostly @Chaho12 @vishalya and @oneonestar
I think env variable is a good way.
We can use env: secretKeyRef
to set env. variable from secret in K8S YAML.
After migrate to Airlift, settings in httpConfig
section are allowed to use env variable (impl. by Airlift).
We might want to add the same function to other sections.
httpConfig:
http-server.https.keystore.path: cert.jks
http-server.https.keystore.key: ${ENV:KEYSTORE_KEY}
Also, the plain text password in presetUsers
section should be gone.
We could use something similar to password file in Trino.
If we decide to pull in io.trino.spi.*
, we could reuse FileAuthenticator from Trino.
The goal of this request is to have the loading of basic configurations and secrets split up to provide a separation of concerns.
An example usage where this would be required would be running Trino Gateway in Kubernetes using the provided Helm chart. Currently, all of the configurations/secrets are merged and mounted to the container as a single YAML file. In order to follow this strategy that means:
lookup
can be done on pre-existing secrets which will be merged into the standalone secretlookup
strategy.Opening this issue to spur conversations on better strategies for configuring the application.
An initial suggestion could be leveraging Jackson's ObjectMapper with YAMLFactory and the
readerForUpdating
functionality. This could support loading of multiple configurations by the following strategy:I'm not 100% sure how Trino is handling this in their Kubernetes deployment but it would be interesting to see if we can follow suit.