Input requested - Optional configuration file(s) for YottaDB

[K.S. Bhaskar]

We would like to request your input on Optional configuration file(s) for YottaDB (https://gitlab.com/YottaDB/DB/YDB/-/work_items/1104#draft-release-note). By way of motivation, the goal is to make YottaDB more like Linux programs such as bash, which reads /etc/profile, $HOME/.bash_login, $HOME/.profile on login, or $HOME/.bashrc on process startup (which can be overridden with command line arguments or environment variables - see man bash or https://www.man7.org/linux/man-pages//man1/bash.1.html) - but in a way that is suited to YottaDB.

We'll take your input in any form - thumbs-up or -down on the draft release notes; a comment in the work item; or an e-mail. One specific question: Is the level of flexibility this provides too confusing?

Thank you very much for your thoughtful inputs.

Regards

- Bhaskar

[Kevin Toppenberg]

No one has replied to you here.  I went and looked at the URL you posted, but I didn't feel I had enough understanding to comment one way or the other. 

Sorry.

Kevin

[K.S. Bhaskar]

Thanks Kevin.

Regards

- Bhaskar

[Christian Caldwell]

Bhaskar,

Thumbs up on the draft release notes. This would help us.

We run YottaDB under Podman for Dev/QA, and we are moving toward multi-org / systemd-style installs. Today we rely on a sourced etc/env (plus compose). That works in containers, but it is easy to miss for services, cron/mupip jobs, and clean restarts — we have already hit “wrong or unset ydb_ci / call-in path” failures when a child process did not inherit the intended env.

What we like:

Optional conf files with clear precedence (existing env wins, then ydb_conf, then the /etc locations)
Especially -use / -u for services: wipe ydb*/gtm* and load one file — that is the right model for systemd units and shebang-style ops scripts
On “is the flexibility too confusing?”: not if sites pick one house style and stick to it. For us that would be something like: containers keep compose + etc/env; production cells use /etc/yottadb.conf (or per-cell ydb_conf) and -use for long-lived services. The confusing case is stacking all three without documenting who wins — the release note’s priority list already addresses that if people read it.

One ask: keep the release note explicit that already-defined environment variables are never overwritten, and that -use is the escape hatch for a known-good, isolated env. That matches how Linux tools behave and will reduce support confusion.

Thanks for asking the community.

Regards

Christian Caldwell

[K.S. Bhaskar]

Thanks for the comments, Christian.

Regards

- Bhaskar