From ecefc48fa83d39bb062961f87d28bcc22e1e2f0a Mon Sep 17 00:00:00 2001 From: jingwenxie Date: Thu, 23 Jan 2025 02:31:47 +0000 Subject: [PATCH 1/6] db_design multi --- doc/multi_asic/DB_Design_for_multi_asic.md | 197 +++++++++++++++++++++ 1 file changed, 197 insertions(+) create mode 100644 doc/multi_asic/DB_Design_for_multi_asic.md diff --git a/doc/multi_asic/DB_Design_for_multi_asic.md b/doc/multi_asic/DB_Design_for_multi_asic.md new file mode 100644 index 0000000000..1995b35f07 --- /dev/null +++ b/doc/multi_asic/DB_Design_for_multi_asic.md @@ -0,0 +1,197 @@ +# DB Design for multi-ASIC scenarios + +- [DB Design for multi-ASIC scenarios](#db-design-for-multi-asic-scenarios) +- [Revision](#revision) +- [1. BACKGROUND](#1----background) +- [2. SCOPE](#2----scope) +- [3. DESIGN OVERVIEW](#3----design-overview) +- [4. DB Schema Design](#4-db-schema-design) +- [5 Requirements](#5-requirements) + * [5.1 config reload ](#51-config-reload--filename--) + * [5.2 config override](#52-config-override) + * [5.3 config apply-patch](#53-config-apply-patch) + * [5.4 show runningconfiguration all](#54-show-runningconfiguration-all) + * [5.5 config save](#55-config-save) +- [6. Conclusion](#6-conclusion) + +# Revision + +| Rev | Date | Author | Change Description | +|:---:|:-----------:|:------------------:|---------------------| +| 0.1 | 09/24/2024 | Jingwen Xie | Initial version | + +# 1. BACKGROUND + +SONiC uses minigraph as configuration truth generation for both single ASIC and multi-ASIC. In multi-ASIC, SONiC itself will generate HOST and ASIC DB configurations based on single minigraph file. +In the future, SONiC will deprecate minigraph and fetch the Golden Config generated by (NDM)Network Device Management team. In the single ASIC workflow, NDM will be responsible to generate the Golden Config. HwProxy(Config Push Service) will push the config to SONiC. Then SONiC will load the Golden Config. However, NDM, HwProxy and SONiC doesn’t have a workflow for multi-asic scenario to consume Golden Config. +In existing minigraph workflow, NDM/HwProxy will treat multi-asic SONiC device just as the single ASIC device, which means only one minigraph file will be provided to SONiC to generate all the configuration no matter it is single ASIC or multi-asic. During multi-asic config generation, a single minigraph will be generated and deployed in SONiC device. SONiC has its minigraph parsing logic to break one piece of config into small pieces for host and each ASIC. +We assume NDM/HwProxy will follow the above existing minigraph workflow, where only one Golden Config file will be generated and deployed in SONiC’s multi-asic device. + + +# 2. SCOPE + +This document describes the high level design of DB schema of multi-asic scenarios. + +# 3. DESIGN OVERVIEW + +A single Golden Config will be provided as the ground truth of multi-asic SONiC configuration source. + +**Objective:** + +This DB design will be used for a single source of truth of multi-asic device configuration in the future. + +**Requirements:** + +- `config reload` should be able to reload one desired Golden Config file for multi-asic. +- `config override-config-table` should be able to perform override one desired Golden Config file for multi-aisc. +- `show runningconfiguration all` should be able to show all host and asics config in the format of desired Golden Config. +- `config apply-patch` should be able to perform config update change based on the Jsondiff of desired Golden Config. +- `config save` should be able to save all config to one file of desired Golden Config format. + + +# 4. DB Schema Design + +The new DB schema provides another layer of Host and Asic as key, then appends relative configuration as the value. +``` +{ + "localhost"：{ + "FEATURE": {…}， + "ACL_TABLE": {…}, + … + }， + "asic0"：{ + "FEATURE": {…}, + "ACL_TABLE": {…}, + … + }, + … +} + +``` + +# 5 Requirements + +## 5.1 config reload + +Current config reload CLI supports multi-asic reload by providing N config files, where N is the sum of host and ASICs. The config file for host will be `/etc/sonic/config_db.json`, and the config file for ASIC will be `/etc/sonic/config_db0.json`, `/etc/sonic/config_db1.json`, and so on. +To support the single Golden Config JSON file described earlier, SONiC should be able to consume one file to generate all configs of host and ASIC. To make it backward compatible, we need to add the multi ASIC support to make it be able to consume one Golden Config JSON file. + +**SCENARIOS** + +1. Existing support for single ASIC: +- `config reload` + It will reload the default config file: /etc/sonic/config_db.json +- `config reload tmp_config_db.json` + It will reload the tmp_config_db.json +2. Existing support for multi-ASIC: +- `config reload` +It will reload the default config file: `/etc/sonic/config_db.json, /etc/sonic/config_db0.json, …, /etc/sonic/config_db5.json` +- `config reload tmp_config_db.json,tmp_config_db0.json,…,tmp_config_db5.json` + It will reload the specified list of tmp config files. +3. Extra support for multi-ASIC: +- `config reload golden_config_db.json` +It will reload the single JSON file with format in chapter 4 to all configDBs. + +## 5.2 config override +Current config override CLI only support single ASIC override. Its logic needs to be modified to support override in multi-asic scenarios. PR +Take one table "MACSEC_PROFILE" for example. Suppose we have golden_config_db.json in below: +``` +{ + "localhost":{ + "MACSEC_PROFILE":{} + }, + "asic0":{ + "MACSEC_PROFILE":{ + "entry":{"k":"v"} + } + }, + "asic1":{ + "MACSEC_PROFILE":{ + "entry":{"k":"v"} + } + }, + … +} +``` +After override, each of ConfigDB should be updated below: +- host: +The MACSEC_PROFILE table will be removed no matter what it was before override since empty json means table removal. +``` +{ + "MACSEC_PROFILE":{}, +} +``` +- asic0, asic1,... +The MACSEC_PROFILE table will be exactly be what resides the golden config no matter what it was. +``` +{ + "MACSEC_PROFILE":{ + "entry":{"k":"v"} + }, +} +``` +## 5.3 config apply-patch + +Current config apply-patch CLI doesn’t support multi-asic. To support GCU in multi-asic, we need to modify the patch to make host and ASIC consume the patch in a loop. +The GCU command will keep the same as before. patch will stays the same and follow JSON Patch (RFC6902). +- config apply-patch patch.json +Example of patch.json. This patch is to change asic0 and asic1’s k to “value”. +``` +[ + { + "op": "replace", + "path": "/asic1/MACSEC_PROFILE/entry/k", + "value": "value" + }, + { + "op": "replace", + "path": "/asic0/MACSEC_PROFILE/entry/k", + "value": "value" + } +] +``` +## 5.4 show runningconfiguration all + +`show runningconfiguration all` should display the configuration of all asic configuration in below format: +``` +{ + "localhost"：{ + "MGMT_INTERFACE": {…}， + "ACL_TABLE": {…}, + … + }， + "asic0"：{ + "MGMT_INTERFACE": {…}, + "ACL_TABLE": {…}, + … + }, + "asic1"：{ + "MGMT_INTERFACE": {…}, + "ACL_TABLE": {…}, + … + }, + … +} +``` +## 5.5 config save +Current config save will generate N config files, where N is the sum of host and ASICs. The CLI will keep the same behavior as before. +SCENARIOS (for Repave?) +1. Existing support for single ASIC: +- `config save` + It will save to the default config file: /etc/sonic/config_db.json +- `config save tmp_config_db.json` + It will save config to the tmp_config_db.json +2. Existing support for multi-ASIC: +- `config save` +It will save to the default config file: /etc/sonic/config_db.json, /etc/sonic/config_db0.json, …, /etc/sonic/config_db5.json +- `config save tmp_config_db.json,tmp_config_db0.json,…,tmp_config_db5.json` + It will save to the specified list of tmp config files. +3. Extra support for multi-ASIC: +- `config save all_config_db.json` +It will save the single JSON file with format of chatper 4 to all configDBs. + + +# 6. Conclusion + +To support this DB schema, all we need to do is to add one layer of host or ASIC information. SONiC YANG models can stay as of now and no new fields need to be added. + From 93b4697b963abff11f97e8b1450e78af312bab35 Mon Sep 17 00:00:00 2001 From: jingwenxie Date: Thu, 23 Jan 2025 02:42:35 +0000 Subject: [PATCH 2/6] patch --- doc/multi_asic/DB_Design_for_multi_asic.md | 69 ++++++++++++---------- 1 file changed, 38 insertions(+), 31 deletions(-) diff --git a/doc/multi_asic/DB_Design_for_multi_asic.md b/doc/multi_asic/DB_Design_for_multi_asic.md index 1995b35f07..20e6f4dd9f 100644 --- a/doc/multi_asic/DB_Design_for_multi_asic.md +++ b/doc/multi_asic/DB_Design_for_multi_asic.md @@ -20,19 +20,20 @@ |:---:|:-----------:|:------------------:|---------------------| | 0.1 | 09/24/2024 | Jingwen Xie | Initial version | -# 1. BACKGROUND +# 1.BACKGROUND SONiC uses minigraph as configuration truth generation for both single ASIC and multi-ASIC. In multi-ASIC, SONiC itself will generate HOST and ASIC DB configurations based on single minigraph file. + In the future, SONiC will deprecate minigraph and fetch the Golden Config generated by (NDM)Network Device Management team. In the single ASIC workflow, NDM will be responsible to generate the Golden Config. HwProxy(Config Push Service) will push the config to SONiC. Then SONiC will load the Golden Config. However, NDM, HwProxy and SONiC doesn’t have a workflow for multi-asic scenario to consume Golden Config. -In existing minigraph workflow, NDM/HwProxy will treat multi-asic SONiC device just as the single ASIC device, which means only one minigraph file will be provided to SONiC to generate all the configuration no matter it is single ASIC or multi-asic. During multi-asic config generation, a single minigraph will be generated and deployed in SONiC device. SONiC has its minigraph parsing logic to break one piece of config into small pieces for host and each ASIC. -We assume NDM/HwProxy will follow the above existing minigraph workflow, where only one Golden Config file will be generated and deployed in SONiC’s multi-asic device. +In existing minigraph workflow, NDM/HwProxy will treat multi-asic SONiC device just as the single ASIC device, which means only one minigraph file will be provided to SONiC to generate all the configuration no matter it is single ASIC or multi-asic. During multi-asic config generation, a single minigraph will be generated and deployed in SONiC device. SONiC has its minigraph parsing logic to break one piece of config into small pieces for host and each ASIC. -# 2. SCOPE +We assume NDM/HwProxy will follow the above existing minigraph workflow, where only one Golden Config file will be generated and deployed in SONiC’s multi-asic device. +# 2.SCOPE This document describes the high level design of DB schema of multi-asic scenarios. -# 3. DESIGN OVERVIEW +# 3.DESIGN OVERVIEW A single Golden Config will be provided as the ground truth of multi-asic SONiC configuration source. @@ -42,14 +43,14 @@ This DB design will be used for a single source of truth of multi-asic device co **Requirements:** -- `config reload` should be able to reload one desired Golden Config file for multi-asic. -- `config override-config-table` should be able to perform override one desired Golden Config file for multi-aisc. -- `show runningconfiguration all` should be able to show all host and asics config in the format of desired Golden Config. -- `config apply-patch` should be able to perform config update change based on the Jsondiff of desired Golden Config. -- `config save` should be able to save all config to one file of desired Golden Config format. +- `config reload` should be able to reload one desired Golden Config file for multi-asic. +- `config override-config-table` should be able to perform override one desired Golden Config file for multi-aisc. +- `show runningconfiguration all` should be able to show all host and asics config in the format of desired Golden Config. +- `config apply-patch` should be able to perform config update change based on the Jsondiff of desired Golden Config. +- `config save` should be able to save all config to one file of desired Golden Config format. -# 4. DB Schema Design +# 4.DB Schema Design The new DB schema provides another layer of Host and Asic as key, then appends relative configuration as the value. ``` @@ -69,31 +70,35 @@ The new DB schema provides another layer of Host and Asic as key, then appends r ``` -# 5 Requirements +# 5.Requirements ## 5.1 config reload Current config reload CLI supports multi-asic reload by providing N config files, where N is the sum of host and ASICs. The config file for host will be `/etc/sonic/config_db.json`, and the config file for ASIC will be `/etc/sonic/config_db0.json`, `/etc/sonic/config_db1.json`, and so on. + To support the single Golden Config JSON file described earlier, SONiC should be able to consume one file to generate all configs of host and ASIC. To make it backward compatible, we need to add the multi ASIC support to make it be able to consume one Golden Config JSON file. **SCENARIOS** -1. Existing support for single ASIC: +1.Existing support for single ASIC: - `config reload` - It will reload the default config file: /etc/sonic/config_db.json +It will reload the default config file: /etc/sonic/config_db.json - `config reload tmp_config_db.json` - It will reload the tmp_config_db.json -2. Existing support for multi-ASIC: +It will reload the tmp_config_db.json + +2.Existing support for multi-ASIC: - `config reload` It will reload the default config file: `/etc/sonic/config_db.json, /etc/sonic/config_db0.json, …, /etc/sonic/config_db5.json` - `config reload tmp_config_db.json,tmp_config_db0.json,…,tmp_config_db5.json` - It will reload the specified list of tmp config files. -3. Extra support for multi-ASIC: -- `config reload golden_config_db.json` +It will reload the specified list of tmp config files. + +3.Extra support for multi-ASIC: +- `config reload golden_config_db.json` It will reload the single JSON file with format in chapter 4 to all configDBs. ## 5.2 config override -Current config override CLI only support single ASIC override. Its logic needs to be modified to support override in multi-asic scenarios. PR +Current config override CLI only support single ASIC override. Its logic needs to be modified to support override in multi-asic scenarios.[PR](https://github.com/sonic-net/sonic-utilities/pull/2738) + Take one table "MACSEC_PROFILE" for example. Suppose we have golden_config_db.json in below: ``` { @@ -115,6 +120,7 @@ Take one table "MACSEC_PROFILE" for example. Suppose we have golden_config_db.js ``` After override, each of ConfigDB should be updated below: - host: + The MACSEC_PROFILE table will be removed no matter what it was before override since empty json means table removal. ``` { @@ -122,6 +128,7 @@ The MACSEC_PROFILE table will be removed no matter what it was before override s } ``` - asic0, asic1,... + The MACSEC_PROFILE table will be exactly be what resides the golden config no matter what it was. ``` { @@ -176,22 +183,22 @@ Example of patch.json. This patch is to change asic0 and asic1’s k to “value ## 5.5 config save Current config save will generate N config files, where N is the sum of host and ASICs. The CLI will keep the same behavior as before. SCENARIOS (for Repave?) -1. Existing support for single ASIC: +1.Existing support for single ASIC: +- `config save` +It will save to the default config file: /etc/sonic/config_db.json +- `config save tmp_config_db.json` +It will save config to the tmp_config_db.json +2.Existing support for multi-ASIC: - `config save` - It will save to the default config file: /etc/sonic/config_db.json -- `config save tmp_config_db.json` - It will save config to the tmp_config_db.json -2. Existing support for multi-ASIC: -- `config save` It will save to the default config file: /etc/sonic/config_db.json, /etc/sonic/config_db0.json, …, /etc/sonic/config_db5.json -- `config save tmp_config_db.json,tmp_config_db0.json,…,tmp_config_db5.json` - It will save to the specified list of tmp config files. -3. Extra support for multi-ASIC: -- `config save all_config_db.json` +- `config save tmp_config_db.json,tmp_config_db0.json,…,tmp_config_db5.json` +It will save to the specified list of tmp config files. +3.Extra support for multi-ASIC: +- `config save all_config_db.json` It will save the single JSON file with format of chatper 4 to all configDBs. -# 6. Conclusion +# 6.Conclusion To support this DB schema, all we need to do is to add one layer of host or ASIC information. SONiC YANG models can stay as of now and no new fields need to be added. From ea9cacbae907b2ab1fa474dae1536f836b229d07 Mon Sep 17 00:00:00 2001 From: jingwenxie Date: Thu, 23 Jan 2025 02:47:32 +0000 Subject: [PATCH 3/6] patch --- doc/multi_asic/DB_Design_for_multi_asic.md | 35 +++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/doc/multi_asic/DB_Design_for_multi_asic.md b/doc/multi_asic/DB_Design_for_multi_asic.md index 20e6f4dd9f..509d08edc2 100644 --- a/doc/multi_asic/DB_Design_for_multi_asic.md +++ b/doc/multi_asic/DB_Design_for_multi_asic.md @@ -24,7 +24,7 @@ SONiC uses minigraph as configuration truth generation for both single ASIC and multi-ASIC. In multi-ASIC, SONiC itself will generate HOST and ASIC DB configurations based on single minigraph file. -In the future, SONiC will deprecate minigraph and fetch the Golden Config generated by (NDM)Network Device Management team. In the single ASIC workflow, NDM will be responsible to generate the Golden Config. HwProxy(Config Push Service) will push the config to SONiC. Then SONiC will load the Golden Config. However, NDM, HwProxy and SONiC doesn’t have a workflow for multi-asic scenario to consume Golden Config. +In the future, SONiC will deprecate minigraph and fetch the Golden Config generated by Network Device Management(NDM) team. In the single ASIC workflow, NDM will be responsible to generate the Golden Config. Config Push Service(HwProxy) will push the config to SONiC. Then SONiC will load the Golden Config. However, NDM, HwProxy and SONiC doesn’t have a workflow for multi-asic scenario to consume Golden Config. In existing minigraph workflow, NDM/HwProxy will treat multi-asic SONiC device just as the single ASIC device, which means only one minigraph file will be provided to SONiC to generate all the configuration no matter it is single ASIC or multi-asic. During multi-asic config generation, a single minigraph will be generated and deployed in SONiC device. SONiC has its minigraph parsing logic to break one piece of config into small pieces for host and each ASIC. @@ -81,25 +81,36 @@ To support the single Golden Config JSON file described earlier, SONiC should be **SCENARIOS** 1.Existing support for single ASIC: + - `config reload` + It will reload the default config file: /etc/sonic/config_db.json + - `config reload tmp_config_db.json` + It will reload the tmp_config_db.json 2.Existing support for multi-ASIC: + - `config reload` + It will reload the default config file: `/etc/sonic/config_db.json, /etc/sonic/config_db0.json, …, /etc/sonic/config_db5.json` + - `config reload tmp_config_db.json,tmp_config_db0.json,…,tmp_config_db5.json` + It will reload the specified list of tmp config files. 3.Extra support for multi-ASIC: + - `config reload golden_config_db.json` + It will reload the single JSON file with format in chapter 4 to all configDBs. ## 5.2 config override Current config override CLI only support single ASIC override. Its logic needs to be modified to support override in multi-asic scenarios.[PR](https://github.com/sonic-net/sonic-utilities/pull/2738) Take one table "MACSEC_PROFILE" for example. Suppose we have golden_config_db.json in below: + ``` { "localhost":{ @@ -118,10 +129,13 @@ Take one table "MACSEC_PROFILE" for example. Suppose we have golden_config_db.js … } ``` + After override, each of ConfigDB should be updated below: + - host: The MACSEC_PROFILE table will be removed no matter what it was before override since empty json means table removal. + ``` { "MACSEC_PROFILE":{}, @@ -141,8 +155,11 @@ The MACSEC_PROFILE table will be exactly be what resides the golden config no ma Current config apply-patch CLI doesn’t support multi-asic. To support GCU in multi-asic, we need to modify the patch to make host and ASIC consume the patch in a loop. The GCU command will keep the same as before. patch will stays the same and follow JSON Patch (RFC6902). + - config apply-patch patch.json + Example of patch.json. This patch is to change asic0 and asic1’s k to “value”. + ``` [ { @@ -156,10 +173,12 @@ Example of patch.json. This patch is to change asic0 and asic1’s k to “value "value": "value" } ] + ``` ## 5.4 show runningconfiguration all `show runningconfiguration all` should display the configuration of all asic configuration in below format: + ``` { "localhost"：{ @@ -180,21 +199,35 @@ Example of patch.json. This patch is to change asic0 and asic1’s k to “value … } ``` + ## 5.5 config save Current config save will generate N config files, where N is the sum of host and ASICs. The CLI will keep the same behavior as before. SCENARIOS (for Repave?) + 1.Existing support for single ASIC: + - `config save` + It will save to the default config file: /etc/sonic/config_db.json + - `config save tmp_config_db.json` + It will save config to the tmp_config_db.json + 2.Existing support for multi-ASIC: + - `config save` + It will save to the default config file: /etc/sonic/config_db.json, /etc/sonic/config_db0.json, …, /etc/sonic/config_db5.json + - `config save tmp_config_db.json,tmp_config_db0.json,…,tmp_config_db5.json` + It will save to the specified list of tmp config files. + 3.Extra support for multi-ASIC: + - `config save all_config_db.json` + It will save the single JSON file with format of chatper 4 to all configDBs. From e0836d374acb17d329f7a9992ed34fbc310c6702 Mon Sep 17 00:00:00 2001 From: jingwenxie Date: Thu, 23 Jan 2025 02:50:16 +0000 Subject: [PATCH 4/6] patch --- doc/multi_asic/DB_Design_for_multi_asic.md | 24 +++++++++++----------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/multi_asic/DB_Design_for_multi_asic.md b/doc/multi_asic/DB_Design_for_multi_asic.md index 509d08edc2..cd2619729d 100644 --- a/doc/multi_asic/DB_Design_for_multi_asic.md +++ b/doc/multi_asic/DB_Design_for_multi_asic.md @@ -2,17 +2,17 @@ - [DB Design for multi-ASIC scenarios](#db-design-for-multi-asic-scenarios) - [Revision](#revision) -- [1. BACKGROUND](#1----background) -- [2. SCOPE](#2----scope) -- [3. DESIGN OVERVIEW](#3----design-overview) -- [4. DB Schema Design](#4-db-schema-design) -- [5 Requirements](#5-requirements) +- [1.BACKGROUND](#1----background) +- [2.SCOPE](#2----scope) +- [3.DESIGN OVERVIEW](#3----design-overview) +- [4.DB Schema Design](#4-db-schema-design) +- [5.Requirements](#5-requirements) * [5.1 config reload ](#51-config-reload--filename--) * [5.2 config override](#52-config-override) * [5.3 config apply-patch](#53-config-apply-patch) * [5.4 show runningconfiguration all](#54-show-runningconfiguration-all) * [5.5 config save](#55-config-save) -- [6. Conclusion](#6-conclusion) +- [6.Conclusion](#6-conclusion) # Revision @@ -80,7 +80,7 @@ To support the single Golden Config JSON file described earlier, SONiC should be **SCENARIOS** -1.Existing support for single ASIC: +1. Existing support for single ASIC: - `config reload` @@ -90,7 +90,7 @@ It will reload the default config file: /etc/sonic/config_db.json It will reload the tmp_config_db.json -2.Existing support for multi-ASIC: +2. Existing support for multi-ASIC: - `config reload` @@ -100,7 +100,7 @@ It will reload the default config file: `/etc/sonic/config_db.json, /etc/sonic/c It will reload the specified list of tmp config files. -3.Extra support for multi-ASIC: +3. Extra support for multi-ASIC: - `config reload golden_config_db.json` @@ -204,7 +204,7 @@ Example of patch.json. This patch is to change asic0 and asic1’s k to “value Current config save will generate N config files, where N is the sum of host and ASICs. The CLI will keep the same behavior as before. SCENARIOS (for Repave?) -1.Existing support for single ASIC: +1. Existing support for single ASIC: - `config save` @@ -214,7 +214,7 @@ It will save to the default config file: /etc/sonic/config_db.json It will save config to the tmp_config_db.json -2.Existing support for multi-ASIC: +2. Existing support for multi-ASIC: - `config save` @@ -224,7 +224,7 @@ It will save to the default config file: /etc/sonic/config_db.json, /etc/sonic/c It will save to the specified list of tmp config files. -3.Extra support for multi-ASIC: +3. Extra support for multi-ASIC: - `config save all_config_db.json` From 5f8bd0646f315e0f9e69758aa0e5dba884ff1425 Mon Sep 17 00:00:00 2001 From: jingwenxie Date: Thu, 23 Jan 2025 02:52:26 +0000 Subject: [PATCH 5/6] patch --- doc/multi_asic/DB_Design_for_multi_asic.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/multi_asic/DB_Design_for_multi_asic.md b/doc/multi_asic/DB_Design_for_multi_asic.md index cd2619729d..d2daff464a 100644 --- a/doc/multi_asic/DB_Design_for_multi_asic.md +++ b/doc/multi_asic/DB_Design_for_multi_asic.md @@ -2,17 +2,17 @@ - [DB Design for multi-ASIC scenarios](#db-design-for-multi-asic-scenarios) - [Revision](#revision) -- [1.BACKGROUND](#1----background) -- [2.SCOPE](#2----scope) -- [3.DESIGN OVERVIEW](#3----design-overview) -- [4.DB Schema Design](#4-db-schema-design) -- [5.Requirements](#5-requirements) +- [1.BACKGROUND](#1background) +- [2.SCOPE](#2scope) +- [3.DESIGN OVERVIEW](#3design-overview) +- [4.DB Schema Design](#4db-schema-design) +- [5.Requirements](#5requirements) * [5.1 config reload ](#51-config-reload--filename--) * [5.2 config override](#52-config-override) * [5.3 config apply-patch](#53-config-apply-patch) * [5.4 show runningconfiguration all](#54-show-runningconfiguration-all) * [5.5 config save](#55-config-save) -- [6.Conclusion](#6-conclusion) +- [6.Conclusion](#6conclusion) # Revision From ce06a0c61edf6d9f96711cda6e6ce42d7649b2e6 Mon Sep 17 00:00:00 2001 From: jingwenxie Date: Thu, 23 Jan 2025 02:54:29 +0000 Subject: [PATCH 6/6] patch --- doc/multi_asic/DB_Design_for_multi_asic.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/multi_asic/DB_Design_for_multi_asic.md b/doc/multi_asic/DB_Design_for_multi_asic.md index d2daff464a..516c860c87 100644 --- a/doc/multi_asic/DB_Design_for_multi_asic.md +++ b/doc/multi_asic/DB_Design_for_multi_asic.md @@ -202,7 +202,7 @@ Example of patch.json. This patch is to change asic0 and asic1’s k to “value ## 5.5 config save Current config save will generate N config files, where N is the sum of host and ASICs. The CLI will keep the same behavior as before. -SCENARIOS (for Repave?) +SCENARIOS 1. Existing support for single ASIC: