rvdduieer4ll5bnmo1ia6pmkqf024rka · 12 rows
| key | value |
|---|---|
| auto_compact_enabled | false |
| compact_batch_size | 50 |
| compact_parallel_workers | 5 |
| compact_tier1_days | 30 |
| compact_tier1_dep_levels | 2 |
| compact_tier2_commits | 100 |
| compact_tier2_days | 90 |
| compact_tier2_dep_levels | 5 |
| compaction_enabled | false |
| issue_prefix | tarantool-etcd |
| kv.memory.self-hosted-etcd-config-coldboot | A Tarantool EE cluster CAN host its own etcd config store (every node runs app.roles.etcd, KV replicated under Raft) and migrate file->etcd live by rolling restart — VERIFIED end-to-end on EE 3.7.0 in examples/tarantool-ee-self-hosted-etcd. Hard rules learned: (1) cannot cold-boot (config.etcd fetches before box.cfg/role-start; all-down = nobody serves etcd = deadlock) — retain local cluster-config.yaml as cold-boot seed; (2) the EE config.etcd source pins to Endpoints[0] and does NOT fail over on 'no leader' (same as clientv3 pick-first) — so TT_CONFIG_ETCD_ENDPOINTS MUST list the current Raft leader FIRST or boot dies on a follower; the boot fetch is NOT a plain Range so read_pref=any doesn't save it; (3) migrate the Raft leader LAST and wait for a stable single-leader between rolling steps. read_pref=any still set as defense for plain Range reads. |
| kv.memory.tarantool-ee-uses-etcd-as-a-centralized-config | Tarantool EE uses etcd as a centralized-config backend (config.storage / etcd source in TT 3.x): on boot it reads config from etcd then opens a Watch with prev_kv set to diff old-vs-new config on live reload. So Watch prev_kv is a first-class ecosystem consumer, not just a conformance checkbox — it gates drop-in TT EE compatibility. Feature is implemented (app/etcd/watch.lua lookup_prev_kv); the open work is the TestWatchWithPrevKV conformance case (tarantool-etcd-9z2, Phase 5f). |