feat: As a user, I want a Valkey config_provider for the data-plane role, so that I can run a decoupled data plane without etcd

オープン
  • 何か問題がありますか？
#13,751 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
lua, redis
領域
api, backend, databases

調査の方向性

まず apisix/core/config_yaml.lua と apisix/core/config_xds.lua にある既存の config provider を読み、次に apisix/cli/schema.lua、apisix/cli/file.lua、apisix/cli/ops.lua、apisix/init.lua にある provider の処理を確認します。data-plane の Valkey provider とその設定カバレッジを追加し、t/config-center-valkey/ を作成し、ci/pod/docker-compose.common.yml に Valkey サービスを追加して、.github/workflows/build.yml にテストグループを組み込みます。Valkey-backed の read および watch パスが統合テストに合格すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

enhancement
Description

As a user running Valkey/Redis-compatible infrastructure, I want to run APISIX data-plane nodes that sync their configuration from Valkey, so that I can operate a decoupled data plane without also running an etcd cluster.

Context

APISIX already supports multiple config_provider options for the data-plane role (etcd, yaml, json, xds). This proposal adds one more — valkey — following the same read-only sync pattern that json and xds established. It is purely additive: etcd remains the default and nothing about the existing providers changes.

Many teams already standardize on Valkey/Redis for their infrastructure (APISIX's own redis-backed plugins are widely used against Valkey today, e.g. #13584, #12282). Letting a data plane sync config from Valkey removes etcd as a hard dependency for those deployments.

Why Valkey can satisfy the config-provider contract

The historical concern with non-etcd config stores (see the FAQ) is the need for resumable watch streams, prefix reads, and atomic updates. Valkey now provides primitives that map cleanly onto these:

  • Change notification → Valkey Streams (XREADGROUP with consumer groups): resumable, at-least-once delivery from the last processed ID, which is exactly the "watch stream" semantic etcd provides. This is stronger than the yaml provider's 1s polling.
  • Prefix / directory reads → one Hash per collection ({apisix}:routes, {apisix}:services, ...): HGETALL returns all items in a collection atomically.
  • Revision tracking → an application-managed counter key ({apisix}:revision), INCRed on each change, used to synthesize the conf_version / modifiedIndex that core.config consumers rely on.
  • Hash-tag {apisix} keeps keys co-located on one shard so the design is Valkey-cluster-safe.

Proposed design (data-plane, read-only)

  • New provider module apisix/core/config_valkey.lua implementing the existing core.config read contract (new, get, fetch_created_obj, close, init, init_worker, plus values / values_hash / conf_version / clean_handlers and filter / checker / item_schema handling) — the same surface config_yaml.lua and config_xds.lua satisfy today.
  • Connect via the existing api7-lua-resty-redis-connector dependency (already used by the redis plugins).
  • Add "valkey" to the data-plane config_provider enum + a valkey connection schema (host, port, password, database, tls) in apisix/cli/schema.lua, with the corresponding edits in apisix/cli/file.lua, apisix/cli/ops.lua, and the config_ready_check allowlist in apisix/init.lua.
  • Config gets written to Valkey by an external process (or a Valkey-backed standalone controller); the data plane only reads and watches. Admin API writes are explicitly out of scope for this issue — this is data-plane sync only, matching how xds works.

Example configuration:

# conf/config.yaml
deployment:
  role: data_plane
  role_data_plane:
    config_provider: valkey
    valkey:
      host: "valkey.example.com"
      port: 6379
      password: "secret"
      database: 0
      tls:
        enabled: true

Testing

  • New t/config-center-valkey/ directory mirroring t/config-center-yaml/ and t/config-center-json/, using --- yaml_config blocks to set the data-plane role + config_provider: valkey.
  • Add a valkey/valkey service to ci/pod/docker-compose.common.yml and wire t/config-center-valkey into the corresponding test group in .github/workflows/build.yml.

Scope note

This is deliberately scoped to the data-plane read path — the pattern with clear precedent. Extending the option to the Admin API / control-plane write path is a larger, separate discussion (it would need a write-side storage abstraction, since the Admin API calls core.etcd directly today) and is not part of this proposal.

I'd like to gauge maintainer interest before writing code, per CONTRIBUTING.md. Does this direction sound acceptable, and are there constraints I should account for in the design? I'm happy to implement it. Thank you!

主要言語
Lua
スター
17.3k
フォーク
3k
平均マージ
4日 16時間
マージ済み PR（30日）
69

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/apisix のほかの issue

apache/apisix の issue をすべて見る

似ている issue

Lua の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。