Topics で読み物として読む

この HLD は実装詳細を含みます。機能の概念・設定・運用を読み物として読みたい場合は Topics 12 章: Multi-ASIC / VoQ / Chassis を参照。

裏取りステータス: code-verified

sonic-utilities/show/main.py の runningconfiguration all は multi-ASIC で output['localhost'] = ... + for ns in ns_list: output[ns] = ... の Golden Config 形式で出力する実装を確認。config/main.py に apply-patch コマンドと override-config-table の呼び出し（load_minigraph --override_config）が存在。namespace ごとのループ展開と YANG validate は generic_config_updater 側で扱われる。

Multi-ASIC Single JSON Configuration（Golden Config に namespace layer）¶

何を解決するか¶

minigraph 廃止後の Golden Config（NDM 生成 → HwProxy で push）を multi-ASIC 機にも適用するための JSON スキーマ拡張¹。従来 multi-ASIC では host 用 config_db.json + ASIC 数だけの config_db<N>.json を別ファイルで持っていた。

本提案は 1 ファイルで host と全 ASIC を表現するため、トップに localhost / asic0 / asic1 の namespace layer を 1 段追加する。CLI 群（config reload / save / override / apply-patch、show runningconfiguration all）も同形式を読み書きできるよう拡張する。

どんなスキーマか¶

{
  "localhost": {
    "FEATURE":   {...},
    "ACL_TABLE": {...}
  },
  "asic0": { "FEATURE": {...}, "ACL_TABLE": {...} },
  "asic1": { ... }
}

CLI 互換のため single-ASIC 機では従来の flat ConfigDB JSON も扱える¹。

どの CLI が変わるか¶

CLI	既存挙動	追加挙動
`config reload`	デフォルト `/etc/sonic/config_db.json`	単一 file で全 ASIC を reload（key で振分け）
`config reload <a.json,b0.json,...>`	カンマ区切り N 個	維持（後方互換）
`config override-config-table`	single-ASIC のみ	multi-ASIC 対応（[sonic-utilities #2738]）
`config apply-patch`	multi-ASIC 非対応	path に `/asicN/<TABLE>/...` を含む JsonPatch をループ展開¹
`show runningconfiguration all`	host のみ	Golden Config 形式で全 ASIC 表示
`config save`	N 個の file 生成	単一 file 保存に対応

apply-patch の例¶

[
  { "op": "replace", "path": "/asic1/MACSEC_PROFILE/entry/k", "value": "value" },
  { "op": "replace", "path": "/asic0/MACSEC_PROFILE/entry/k", "value": "value" }
]

CLI は patch を per-namespace ループで分割し、各 namespace の Generic Config Update flow に流す¹。JsonPatch (RFC 6902) 自体は変更しない。

Reload / Save の流れ¶

flowchart LR
  GC["Golden Config JSON<br/>(localhost/asic0/asic1...)"]
  GC --> RELOAD[config reload &lt;file&gt;]
  RELOAD --> NS{namespace 分割}
  NS --> H[host ConfigDB]
  NS --> A0[asic0 ConfigDB]
  NS --> A1[asic1 ConfigDB]
  SAVE[config save &lt;file&gt;] --> AGG[host + 全 asic を集約]
  AGG --> GC

YANG はどう当てるか¶

Top に namespace layer が増えたままでは既存 YANG では検証できない。namespace 単位（host / 各 asic）に分割して既存 YANG で validate すれば良いという整理¹。新フィールドは不要。

Pros / Cons¶

	内容
Pros	namespace 1 layer 追加だけで実装可、既存 YANG 流用、minigraph 廃止 → Golden Config Override へ素直に移行
Cons	全体 YANG を当てられない（分割必要）、namespace 間で重複する table が冗長

📋 検証エビデンス: sonic-net/SONiC/doc/golden_config/Multi-Asic_Single_JSON_Configuration_Design.md#L83-L97 (sha: 49bab5b5ff0e924f1ea52b3d9db0dfa4191a7c06)

出典:

sonic-net/SONiC/doc/golden_config/Multi-Asic_Single_JSON_Configuration_Design.md#L83-L97 (sha: 49bab5b5ff0e924f1ea52b3d9db0dfa4191a7c06)

抜粋:

This design provides another layer of Host and ASIC as keys ...
"localhost": { ... }, "asic0": { ... }, "asic1": { ... }

判断根拠: namespace layer 1 段追加でスキーマ拡張する設計の根拠。

制限事項¶

全体 YANG validate 不可、namespace 単位 validate に留まる
各 ASIC で重複する table は NDM 側でも冗長記述が必要
minigraph 廃止前提のため、minigraph 併用時の挙動はスコープ外

干渉する機能¶

Generic Config Update / Rollback: config apply-patch がループ呼び出しで連動
NDM / HwProxy / Golden Config 生成: 単一 file 前提
YANG validation: namespace ごとに分割適用
multi-asic ConfigDB redis instance: namespace ごとに別インスタンス