tarantool / tarantool/tarantool

config: change working directory before the first `box.cfg()`

Open
#13,086 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

config feature
Dominant language
Lua
Stars
3.7k
Forks
419
Avg merge
1d 23h
Merged PRs (30d)
88

Description

Paths in the configuration are specified relatively to process.work_dir, but the process enters that directory only inside the first box.cfg() call. Everything that runs earlier sees the startup directory instead (e.g. / under systemd), so the config module compensates by hand in several places (see #12610, #12928 and #13025).

We can chdir into process.work_dir right after the configuration collection, before any applier runs. The not-yet-chdir compensation code be dropped in that case. Only the very first config collection from sources and validation has to stay special.

Things to handle:

  • Create a workdir before the chdir.
  • Pass an absolute workdir to box.cfg() on startup and every reload (otherwise a relative path is applied twice and the non-dynamic check trips)
  • Replace the type(box.cfg) predicates with an explicit flag or remove them

Note: the behavior change for early_load roles/app, whose relative fs paths become relative to workdir.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Trace the first configuration collection, validation, and applier sequence around box.cfg(), using the compensation cases referenced by #12610, #12928, and #13025. Check startup and reload handling, including early_load roles/apps and workdir creation. Done means relative paths resolve from process.work_dir, startup and reload pass an absolute workdir, and the existing type(box.cfg) predicates are no longer needed.

Written by the indexing model from the issue text.

Assessment

Tech stack
lua
Domain
backend
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.