[I] Support exporting install configuration as environment variables for stateless deployments [answer]

["bestony (via GitHub)" <gi...@apache.org>]

bestony opened a new issue, #1559:
URL: https://github.com/apache/answer/issues/1559

   ## Is your feature request related to a problem? Please describe
   
   Answer's installation flow generates `/data/conf/config.yaml`, and the Helm chart notes that persistence is required so `config.yaml` survives restarts. `AUTO_INSTALL` accepts environment variables for initial setup, but those variables are not used as the runtime configuration afterward.
   
   This makes configuration-stateless container deployments difficult. A pod with a disposable filesystem cannot restart or scale from an already initialized external database using environment variables and secrets alone. Operators must persist or mount the generated `config.yaml`, or rerun the one-time installer, which is not appropriate once the database has already been initialized.
   
   ## Describe the solution you'd like
   
   Please allow the install flow to export the effective post-install configuration as a complete, documented set of environment variables, and allow normal Answer startup to consume those variables without requiring `config.yaml`.
   
   Expected behavior could include:
   
   - An explicit install option or endpoint that exports the effective runtime configuration in a machine-readable environment-variable format, such as dotenv or shell output.
   - An environment-variable equivalent for every `config.yaml` value required at runtime, with documented precedence when both sources are present.
   - A fresh Answer instance can connect to an already initialized external database and start using only the exported environment variables, without a local `config.yaml`.
   - Secrets are never printed to ordinary logs; exporting secret-bearing values requires an explicit action and can be directed to a secret manager.
   - Existing `config.yaml`-based deployments remain backward compatible.
   
   This would make Answer easier to run with immutable images, disposable pods, Kubernetes Secrets, and externally managed databases.
   
   ## Describe alternatives you've considered
   
   - Persist `/data/conf` on a volume.
   - Generate and mount `config.yaml` from a ConfigMap or Secret.
   - Use an init container or entrypoint template to recreate `config.yaml` on every start.
   - Keep using `AUTO_INSTALL`, although it is a one-time initialization path and fails or becomes inappropriate after the database has already been initialized.
   


-- 
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: issues-unsubscribe@answer.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@answer.apache.org
For additional commands, e-mail: issues-help@answer.apache.org

Re: [I] Support exporting install configuration as environment variables for stateless deployments [answer]

["sneha205985 (via GitHub)" <gi...@apache.org>]

sneha205985 commented on issue #1559:
URL: https://github.com/apache/answer/issues/1559#issuecomment-5044348832

   Hi! I’m interested in working on this as my first contribution. I’ll start exploring the codebase and would be happy to work on it if no one else is currently implementing it.


-- 
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: issues-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@answer.apache.org
For additional commands, e-mail: issues-help@answer.apache.org

Re: [I] Support exporting install configuration as environment variables for stateless deployments [answer]

["ifox777 (via GitHub)" <gi...@apache.org>]

ifox777 commented on issue #1559:
URL: https://github.com/apache/answer/issues/1559#issuecomment-5043280224

   Hi! I’d like to work on this.
   
   After looking through the current install/config flow, this seems larger than a single first PR because runtime config, env precedence, export format, and secret handling are coupled.
   
   Would you be open to splitting it into smaller PRs?
   
   A possible first PR could focus on:
   - defining env > config file > defaults precedence for runtime configuration;
   - supporting the core server/database/cache-related settings from env;
   - adding tests and docs for this behavior;
   
   and leave explicit config export / dotenv generation / secret-manager integration for follow-ups.
   
   Does this split match what you expect for this issue, or would you prefer a different first slice?


-- 
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: issues-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@answer.apache.org
For additional commands, e-mail: issues-help@answer.apache.org