diff --git a/doc/mgmt/Management Framework.md b/doc/mgmt/Management Framework.md index 9fe54c3834..1016ed7302 100644 --- a/doc/mgmt/Management Framework.md +++ b/doc/mgmt/Management Framework.md @@ -88,6 +88,7 @@ * [4.3 Translib Initialization flow](#43-Translib-initialization-flow) * [4.4 gNMI flow](#44-gNMI-flow) * [4.5 CVL flow](#45-CVL-flow) + * [4.6 Bulk flow](#46-Bulk-flow) * [5 Developer Work flow](#5-Developer-Work-flow) * [5.1 Developer work flow for custom (SONiC/CVL) YANG](#51-Developer-work-flow-for-custom-SONiCCVL-YANG) * [5.1.1 Define Config Validation YANG schema](#511-Define-Config-Validation-YANG-schema) @@ -139,6 +140,7 @@ | 0.17 | 04/08/2020 | Mohammed Faraaz | OpenAPI 3.0 enhancements | | 0.18 | 04/09/2020 | Kwangsuk Kim | Updated CLI and Transformer enhancement | | 0.19 | 04/15/2020 | Mohammed Faraaz | Generic REST client for CLI | +| 0.20 | 05/21/2024 | Gandhi Sevagan | Multiple DB extensions | ## About this Manual @@ -216,8 +218,8 @@ Management framework makes use of the translation library (Translib) written in #### 1.2.2 Container The management framework is designed to run in a single container named “sonic-mgmt-framework”. The container includes the REST server linked with Translib, and CLI process. -The gNMI support requires the gNMI server which is provided as a part of sonic-telemetry container. We would like to rename this container as the sonic-gnmi container as now it can perform configurations as well through the gNMI server. -Will introduce a new container sonic-mgmt-common to host the common code that is used both in the mgmt-framework and sonic-telemetry container. This new repo will compile into static libraries that will be used in the other two repos. This way sonic-telemetry repo can be compiled without the mgmt-framework being present in the code base. +The gNMI support requires the gNMI server which is provided as a part of sonic-gnmi container. +A new repo sonic-mgmt-common to host the common code that is used both in the mgmt-framework and sonic-gnmi container. This new repo will compile into static libraries that will be used in the other two repos. This way sonic-gnmi repo can be compiled without the mgmt-framework being present in the code base. ## 2 Functionality @@ -710,7 +712,7 @@ Client applications can use OpenAPI generated client SDK or any other REST clien ##### 3.2.2.3 gNMI Client -SONiC Telemetry service provides the gNMI server, while the client must be provided by the user. gNMI is typically used as a programmatic interface and therefore it is typically called directly from programming language environments using their respective gRPC libraries (https://github.com/grpc/grpc). For testing and scripting purposes, several CLI programs are provided as well. +SONiC GNMI service provides the gNMI server, while the client must be provided by the user. gNMI is typically used as a programmatic interface and therefore it is typically called directly from programming language environments using their respective gRPC libraries (https://github.com/grpc/grpc). For testing and scripting purposes, several CLI programs are provided as well. GNMI clients developed by google and modified by JipanYANG.(github.com/jipanYANG/gnxi/gnmi_get, github.com/jipanYANG/gnxi/gnmi_set) was taken and further modified to support new features. gnmi_cli from openconfig (https://github.com/openconfig/gnmi/tree/master/cmd/gnmi_cli) is also taken for testing subscribe and capabilities operations. Finally, a new client was developed gnoi_client, for test gNOI RPC operations. @@ -1273,6 +1275,16 @@ App Interface helps in identifying the App module responsible for servicing the Translib request handlers use the App interface to get all the App module information depending on the incoming path as part of the requests. +A new interface, named getNamespace, has been introduced in appInterface to retrieve the namespace associated with a YANG node's XPath. All applications including common app will define the wrapper function which will invoke the actual getNamespace function associated with yang node which is defined in the transformation of corresponding yang module. + +// Interface for all App Modules +type appInterface interface { + initialize(data appData) + . + . + getNamespace(path string) ([]string, error) +} + ###### 3.2.2.6.2 Translib Request Handler These are the handlers for the APIs exposed by the Translib. Whenever a request lands in the request handler, the handler uses the App interface to get the App module that can process the request based on the incoming path. It then uses the YGOT binder module, if needed, to convert the incoming path and payload from the request into YGOT structures. The filled YGOT structures are given to the App Modules for processing. The Translib also interacts with the DB access layer to start, commit and abort a transaction. @@ -1808,6 +1820,7 @@ type yangXpathInfo struct { validateFunc string rpcFunc string xfmrKey string + namespaceFunc string keyName *string dbIndex db.DBNum keyLevel int @@ -1823,6 +1836,9 @@ Transformer has a built-in default transformer method to perform static, simple Additionally, for more complex translations of non-ABNF YANG models, i.e. OpenConfig models, Transformer also allows developers to overload the default method by specifying a callback fucntion in YANG extensions, to perform translations with developer-supplied translation codes as callback functions. Transformer dynamically invokes those functions instead of using default method. Each transformer callback must be defined to support two-way translation, i.e, YangToDb_ and DbToYang_, which are invoked by Transformer core. +Transformer also has callback funtion in YANG extensions to get namespace associated with the uri path. This will be mainly useful in case of Multi ASIC platform with multiple Redis DBs. The namespace callback function will be specific to every YANG model defined with its annotations. Translib/transformer shall use "HOST" DB as default for YANG models without namespace extension defined. +Note: getNameSpace can be defined at any subpath level, however it is not recommended to override/terminate at its descendant objects. + ###### 3.2.2.7.3 Process CRUD requests (configuration) are processed via the following steps: @@ -1922,7 +1938,85 @@ The table-transformer is inherited to all descendant nodes unless another one is 11. `sonic-ext:get-validate [function]`: A special hook to validate YANG nodes, to populate data read from database, allows developers to instruct Transformer to choose a YANG node among multiple nodes, while constructing the response payload. Typically used to check the “when” condition to validate YANG node among multiple nodes to choose only valid nodes from sibling nodes. +12. `sonic-ext:get-namespace [function]`: +Multiple DB extension, populates associated namespaces with the YANG path +Used by Translib service to get all DB's associated with the YANG path. In case of single DB, this extension shall not be used. +Namespace yang extension shall allow override capability to allow product specific customizations +```Sample annotation +get-namespace annotation sample for openconfig-optical-amplifier yang support: + +Annotation YANG File: +sonic-mgmt-common/models/yang/annotations/openconfig-optical-amplifier-annot.yang +module openconfig-optical-amplifier-annot { + ..... + deviation /oc-opt-amp:optical-amplifier/oc-opt-amp:amplifiers { + deviate add { + // Default db-name is CONFIG_DB + sonic-ext:table-name "AMPLIFIER"; + } + } + + deviation /oc-opt-amp:optical-amplifier/oc-opt-amp:amplifiers/oc-opt-amp:amplifier { + deviate add { + sonic-ext:key-transformer "oa_name_key_xfmr"; + sonic-ext:get-namespace "oa_name_get_namespace_xfmr"; + } + } + + ..... + deviation /oc-opt-amp:optical-amplifier/oc-opt-amp:supervisory-channels { + deviate add { + sonic-ext:db-name "STATE_DB"; + sonic-ext:table-name "OSC_TABLE"; + } + } + + deviation /oc-opt-amp:optical-amplifier/oc-opt-amp:supervisory-channels/oc-opt-amp:supervisory-channel { + deviate add { + sonic-ext:key-transformer "osc_key_xfmr"; + sonic-ext:get-namespace "oa_name_get_namespace_xfmr"; + } + } + ..... +} + +Annotation implementation function +sonic-mgmt-common/translib/transformer/xfmr_oa.go + +func init () { + ..... + XlateFuncBind("oc_name_get_namespace_xfmr", oc_name_get_namespace_xfmr) +} +var oa_name_get_namespace_xfmr GetNamespaceFunc = func(inParams XfmrParams) ([]string, error) { + var nameSpaceList []string + + log.Info("oa_name_get_namespace_xfmr: ", inParams.ygRoot, inParams.uri) + + oa := getAmplifierRootObj(inParams.ygRoot) + + if strings.Contains(inParams.uri, "/amplifier") && oa.Amplifiers != nil { + for key := range oa.Amplifiers.Amplifier { + log.Info("oa_name_get_namespace_xfmr: keys ", key) + nameSpaceList = append(nameSpaceList, db.GetMDBNameFromEntity(key)) + } + } else if strings.Contains(inParams.uri, "/supervisory-channel") && oa.SupervisoryChannels != nil { + for key := range oa.SupervisoryChannels.SupervisoryChannel { + log.Info("oa_name_get_namespace_xfmr: keys ", key) + nameSpaceList = append(nameSpaceList, db.GetMDBNameFromEntity(key)) + } + } + + if len(nameSpaceList) == 0 { + // For Get requests without key in xpath * is returned. + log.Infof("No specific key found, using '*' to include all DBs.") + nameSpaceList = append(nameSpaceList, "*") + } + + return nameSpaceList, nil +} + +``` ---------- @@ -1942,12 +2036,14 @@ Here is the general guide you can check to find which extensions can be annotate ###### 3.2.2.7.6 Public Functions -`XlateToDb()` and `GetAndXlateFromDb` are used by the common app to request translations. +`XlateToDb()`, `GetAndXlateFromDb` and `GetNameSpace` are used by the common app to request translations. ```go func XlateToDb(path string, opcode int, d *db.DB, yg *ygot.GoStruct, yt *interface{}) (map[string]map[string]db.Value, error) {} func GetAndXlateFromDB(xpath string, uri *ygot.GoStruct, dbs [db.MaxDB]*db.DB) ([]byte, error) {} + +func GetNameSpace(path string, ygotRoot *ygot.GoStruct) ([]string, error) {} ``` ###### 3.2.2.7.7 Overloaded Methods @@ -2040,6 +2136,12 @@ type PostXfmrFunc func (inParams XfmrParams) (map[string]map[string]db.Value, er * Return: List of table names, error **/ type TableXfmrFunc func (inParams XfmrParams) ([]string, error) +/** + * NamespaceFunc type is defined to retrieve namespace associated with the uri path. + * Param: XfmrParams structure having operation, uri + * Return: List of namespace names, error + **/ +type NamespaceFunc func (inParams XfmrParams) ([]string, error) ``` @@ -2369,7 +2471,7 @@ mechanism for the app specific configuration. ### 4.1 REST SET flow -![REST SET flow](images/write.jpg) +![REST SET flow](images/write_mdb.jpg) 1. REST client can send any of the write commands such as POST, PUT, PATCH or DELETE and it will be handled by the REST Gateway. 2. All handlers in the REST gateway will invoke a command request handler. @@ -2380,33 +2482,45 @@ mechanism for the app specific configuration. 7. Translib infra gets the App module corresponding to the incoming URI. 8. Translib infra calls the initialize function of the App module with the YGOT structures, path and payload. 9. App module caches the incoming data into the app structure. -10. App module calls Transformer function to translate the request from cached YGOT structures into Redis ABNF format. It also gets all the keys that will be affected as part of this request. -11. App module returns the list of keys that it wants to keep a watch on along with the status. -12. Translib infra invokes the start transaction request exposed by the DB access layer. -13. DB access layer performs a WATCH of all the keys in the Redis DB. If any of these keys are modified externally then the EXEC call in step 26 will fail. -14. Status being returned from Redis. -15. Status being returned from DB access layer. -16. Translib then invokes the processWrite API on the App module. -17. App modules perform writes of the translated data to the DB access layer. -18. DB access layer validates the writes using CVL and then caches them. -19. Status being returned from DB access layer. -20. Status being returned from App module. -21. Translib infra invokes the commit transaction on the DB access layer. -22. DB access layer first invokes MULTI request on the Redis DB indicating there are multiple writes coming in, so commit everything together. All writes succeed or nothing succeeds. -23. Status returned from Redis. -24. Pipeline of all the cached writes are executed from the DB access layer. -25. Status retuned from Redis. -26. EXEC call is made to the Redis DB. Here if the call fails, it indicates that one of the keys that we watched has changed and none of the writes will go into the Redis DB. -27. Status returned from Redis DB. -28. Status returned from DB access layer. -29. Write lock acquired in Step 6 is released. -30. Status returned from the Translib infra. -31. REST Status returned from the Request handler. -32. REST response is sent by the REST gateway to the REST client. +10. App module returns after initializing local data +11. Translib infra invoke App module getNamespace API (introduced in app interface) to get namespace associated with the uri/payload +12. App module invokes transformer service getNamespaceMapping to retrieve namespace based on Yang model +13. Transformer invokes Yang model based exception to retrieve the namespace associated with uri/payload +14. Transformer returns namespace associated with the uri/payload +15. Appmodule returns namespace +16. Compare retured Namespace, Check that Set operation is restricted to single Namespace +17. Get the Config DB for the selected Namespace +18. App module calls Transformer function to translate the request from cached YGOT structures into Redis ABNF format. It also gets all the keys that will be affected as part of this request. +19. App module returns the list of keys that it wants to keep a watch on along with the status. +20. Translib infra invokes the start transaction request exposed by the DB access layer. +21. DB access layer performs a WATCH of all the keys in the Redis DB. If any of these keys are modified externally then the EXEC call in step 33 will fail. +22. Status being returned from Redis. +23. Status being returned from DB access layer. +24. Translib then invokes the processWrite API on the App module. +25. App modules perform writes of the translated data to the DB access layer. +26. DB access layer validates the writes using CVL and then caches them. +27. Status being returned from DB access layer. +28. Status being returned from App module. +29. If Set was successful, Translib infra invokes the commit transaction on the DB access layer. +30. DB access layer first invokes MULTI request on the Redis DB indicating there are multiple writes coming in, so commit everything together. All writes succeed or nothing succeeds. +31. Status returned from Redis. +32. Pipeline of all the cached writes are executed from the DB access layer. +33. Status retuned from Redis. +34. EXEC call is made to the Redis DB. Here if the call fails, it indicates that one of the keys that we watched has changed and none of the writes will go into the Redis DB. +35. Status returned from Redis DB. +36. Status returned from DB access layer. +37. If Set was a failure, Translib infra invokes the abort transaction on the DB access layer. +38. DB access layer first invokes UNWATCH request on the Redis DB indicating abort everything together. +39. Status retuned from Redis. +40. Status returned from DB access layer. +41. Write lock acquired in Step 6 is released. +42. Status returned from the Translib infra. +43. REST Status returned from the Request handler. +44. REST response is sent by the REST gateway to the REST client. ### 4.2 REST GET flow -![REST GET flow](images/read.jpg) +![REST GET flow](images/read_mdb.jpg) 1. REST GET request from the REST client is sent to the REST Gateway. 2. REST Gateway invokes a common request handler. @@ -2415,17 +2529,24 @@ mechanism for the app specific configuration. 5. Translib infra gets the App module corresponding to the incoming uri. 6. Translib infra calls the initialize function of the App module with the YGOT structures and path. App module caches them. 7. Status retuned from App module. -8. App module queries Transformer to translate the path to the Redis keys that need to be queried. -9. Status returned from App module. -10. Translib infra calls the processGet function on the App module -11. App modules calls read APIs exposed by the DB access layer to read data from the Redis DB. -12. Data is read from the Redis DB is returned to the App module -13. App module fills the YGOT structure with the data from the Redis DB and validated the filled YGOT structure for the syntax. -14. App module converts the YGOT structures to JSON format. -15. IETF JSON payload is returned to the Translib infra. -16. IETF JSON payload is returned to the request handler. -17. Response is returned to REST gateway. -18. REST response is returned to the REST client from the REST gateway. +8. Translib infra calls the getNamespace function of the App module with the uri path, to get all DB namespace associated with the uri path +9. App module queries Transformer to get all namespace associated with the uri path +10. Transformer shall use Yang specific "Transformer Spec" to get all namespace associated with uri path +11. Transformer return namespace associated with the uri path +12. App module return namespace retrived by the transformer layer +13. Translib infra gets all the namespaces available in the platform, loops through each of the namespace associated with the uri path as recieved in earlier step +14. App module queries Transformer to translate the path to the Redis keys that need to be queried. +15. Status returned from App module. +16. Translib infra calls the processGet function on the App module +17. App modules calls read APIs exposed by the DB access layer to read data from the Redis DB. +18. Data is read from the Redis DB is returned to the App module +19. App module fills the YGOT structure with the data from the Redis DB and validated the filled YGOT structure for the syntax. +20. App module converts the YGOT structures to JSON format. +21. IETF JSON payload is returned to the Translib infra. +22. Translib infra aggregates all the responses from app module with different namesapce DB associated with uri path +23. IETF JSON payload is returned to the request handler. +24. Response is returned to REST gateway. +25. REST response is returned to the REST client from the REST gateway. ### 4.3 Translib Initialization flow @@ -2451,7 +2572,7 @@ This way multiple app modules initialize with the Translib infra during boot up. ### 4.5 CVL flow -![CVL flow](images/CVL_flow.jpg) +![CVL flow](images/CVL_flow_mdb.jpg) Above is the sequence diagram explaining the CVL steps. Note that interaction between DB Access layer and Redis including transactions is not shown here for brevity. @@ -2460,27 +2581,98 @@ Above is the sequence diagram explaining the CVL steps. Note that interaction be 3. Translib acquires the write lock (mutex lock) to avoid another write happening from the same process at the same time. 4. Translib infra gets the App module corresponding to the incoming uri. 5. Translib infra calls the initialize function of the App module with the YGOT structures, path and payload. -6. App module calls Transformer to translate the request from cached YGOT structure into Redis ABNF format. It also gets all the keys that will be affected as part of this request. -7. App modules returns the list of keys that it wants to keep a watch on along with the status. -8. Translib infra invokes the start transaction request exposed by the DB access layer. -9. Status being returned from DB access layer. -10. Translib then invokes the processWrite API on the App module. -11. App modules perform writes of the translated data to the DB access layer. -12. DB access layer calls validateWrite for CREATE/UPDATE/DELETE operation. It is called with keys and Redis/ABNF payload. -13. validateSyntax() feeds Redis data to translator internally which produces YANG XML. This is fed to libyang for validating the syntax. -14. If it is successful, control goes to next step, else error is returned to DB access layer. The next step is to ensure that keys are present in Redis DB for Update/Delete operation. But keys should not be present for Create operation. -15. Status is returned after checking keys. -16. CVL gets dependent data from incoming Redis payload. For example if ACL_TABLE and ACL_RULE is getting created in a single request. -17. Otherwise dependent should be present in Redis DB, query is sent to Redis to fetch it. -18. Redis returns response to the query. -19. Finally request data and dependent is merged and validateSemantics() is called. -20. If above step is successful, success is returned or else failure is returned with error details. -21. DB Access layer forwards the status response to App mpdule. -22. App module forwards the status response to Translib infra. -23. Translib infra invokes the commit transaction on the DB access layer. -24. Status is returned from DB access layer after performing commit operation. -25. Write lock acquired in Step 3 is released. -26. Final response is returned from the Translib infra to REST/GNMI. +6. App module caches the incoming data into the app structure. +7. App module returns after initializing local data +8. Translib infra invokes getNameSpace API of the App module +9. App module invokes getNameSpaceMapping Transformer API +10. Transformer invokes Yang model specific getNameSpace annotation function +11. Transformer returns the namespace associated with the uri path +12. App module returns namespace associated with the uri path +13. Compare retured Namespace, Check that Set operation is restricted to single Namespace +14. Get the Config DB for the selected Namespace +15. App module calls Transformer function to translate the request from cached YGOT structures into Redis ABNF format. It also gets all the keys that will be affected as part of this request. +16. App module returns the list of keys that it wants to keep a watch on along with the status. +17. Translib infra invokes the start transaction request exposed by the DB access layer. +18. Status being returned from DB access layer. +19. Translib then invokes the processWrite API on the App module. +20. App modules perform writes of the translated data to the DB access layer. +21. DB access layer calls validateWrite for CREATE/UPDATE/DELETE operation. It is called with keys and Redis/ABNF payload. +22. validateSyntax() feeds Redis data to translator internally which produces YANG XML. This is fed to libyang for validating the syntax. +23. If it is successful, control goes to next step, else error is returned to DB access layer. The next step is to ensure that keys are present in Redis DB for Update/Delete operation. But keys should not be present for Create operation. +24. Status is returned after checking keys. +25. CVL gets dependent data from incoming Redis payload. For example if ACL_TABLE and ACL_RULE is getting created in a single request. +26. Otherwise dependent should be present in Redis DB, query is sent to Redis to fetch it. +27. Redis returns response to the query. +28. Finally request data and dependent is merged and validateSemantics() is called. +29. If above step is successful, success is returned or else failure is returned with error details. +30. DB Access layer forwards the status response to App mpdule. +31. App module forwards the status response to Translib infra. +32. If Successul, Translib infra invokes the commit transaction on the DB access layer. +33. Status is returned from DB access layer after performing commit operation. +34. If Failure, Translib infra invokes the Abort transaction on the DB access layer. +35. Status is returned from DB access layer after performing Abort operation. +36. Write lock acquired in Step 3 is released. +37. Final response is returned from the Translib infra to REST/GNMI. + +### 4.6 Bulk flow + +![Bulk flow](images/bulk_mdb.jpg) + +1. REST client can send any of the write commands such as POST, PUT, PATCH or DELETE and it will be handled by the REST Gateway. +2. All handlers in the REST gateway will invoke a command request handler. +3. Authentication and authorization of the commands are done here. +4. Request handler invokes one of the bulk APIs exposed by the Translib. +5. Translib infra populates the YGOT structure with the payload of the request and performs a syntactic validation +6. Translib acquires the write lock (mutex lock) to avoid another write happening from the same process at the same time. +7. Check all operations is restricted to single namespace, Translib infra gets the App module corresponding to the incoming URI +8. Translib infra calls the initialize function of the App module with the YGOT structures, path and payload. +9. App module caches the incoming data into the app structure. +10. App module returns after initializing local data +11. Translib infra invoke App module getNamespace API (introduced in app interface) to get namespace associated with the uri +12. App module invokes transformer service getNamespaceMapping to retrieve namespace based on Yang model +13. Transformer invokes Yang model based exception to retrieve the namespace associated with uri +14. Transformer returns namespace associated with the uri +15. Appmodule returns namespace +16. Compare retured Namespace, Check that operation is restricted to single Namespace +17. If Single Namespace, Get the Config DB for the selected Namespace +18. Loop through all DeleteRequest + 1. App module calls Transformer function to translate the request from cached YGOT structures into Redis ABNF format. It also gets all the keys that will be affected as part of this request. + 2. App module returns the list of keys that it wants to keep a watch on along with the status. + 3. Translib infra invokes the start transaction request exposed by the DB access layer. + 4. DB access layer performs a WATCH of all the keys in the Redis DB. If any of these keys are modified externally then the EXEC call in step 33 will fail. + 5. Status being returned from Redis. + 6. Status being returned from DB access layer. + 7. Translib then invokes the process Operation API on the App module. + 8. App modules perform operation of the translated data to the DB access layer. + 9. DB access layer validates the operation using CVL and then caches them. + 10. Status being returned from DB access layer. + 11. Status being returned from App module. + 12. If Set was a failure, Translib infra invokes the abort transaction on the DB access layer. + 13. DB access layer first invokes UNWATCH request on the Redis DB indicating abort everything together. + 14. Status retuned from Redis. + 15. Status returned from DB access layer. +19. Loop all Replace Request + Same as 18.1 to 18.15 +20. Loop all Update Request + Same as 18.1 to 18.15 +21. Loop all Create Request + Same as 18.1 to 18.15 +22. If Set was successful, Translib infra invokes the commit transaction on the DB access layer. +23. DB access layer first invokes MULTI request on the Redis DB indicating there are multiple writes coming in, so commit everything together. All writes succeed or nothing succeeds. +24. Status returned from Redis. +25. Pipeline of all the cached writes are executed from the DB access layer. +26. Status retuned from Redis. +27. EXEC call is made to the Redis DB. Here if the call fails, it indicates that one of the keys that we watched has changed and none of the writes will go into the Redis DB. +28. Status returned from Redis DB. +29. Status returned from DB access layer. +30. If Set was a failure, Translib infra invokes the abort transaction on the DB access layer. +31. DB access layer first invokes UNWATCH request on the Redis DB indicating abort everything together. +32. Status retuned from Redis. +33. Status returned from DB access layer. +34. Write lock acquired in Step 6 is released. +35. Status returned from the Translib infra. +36. REST Status returned from the Request handler. +37. REST response is sent by the REST gateway to the REST client. ## 5 Developer Work flow Developer work flow differs for standard YANG (IETF/OpenConfig) vs proprietary YANG used for a feature. When a standards-based YANG model is chosen for a new feature, the associated Redis DB design should take the design of this model into account - the closer the mapping between these, then the less translation logic is required in the Management path. This simplifies the work flow as translation intelligence can be avoided as both Redis schema and NB YANG schema are aligned. diff --git a/doc/mgmt/images/CVL_flow_mdb.jpg b/doc/mgmt/images/CVL_flow_mdb.jpg new file mode 100644 index 0000000000..e8d7572267 Binary files /dev/null and b/doc/mgmt/images/CVL_flow_mdb.jpg differ diff --git a/doc/mgmt/images/bulk_mdb.jpg b/doc/mgmt/images/bulk_mdb.jpg new file mode 100644 index 0000000000..576d11e502 Binary files /dev/null and b/doc/mgmt/images/bulk_mdb.jpg differ diff --git a/doc/mgmt/images/read_mdb.jpg b/doc/mgmt/images/read_mdb.jpg new file mode 100644 index 0000000000..0cdeadab4f Binary files /dev/null and b/doc/mgmt/images/read_mdb.jpg differ diff --git a/doc/mgmt/images/write_mdb.jpg b/doc/mgmt/images/write_mdb.jpg new file mode 100644 index 0000000000..b33cb6eb68 Binary files /dev/null and b/doc/mgmt/images/write_mdb.jpg differ diff --git a/doc/multi_asic/SONiC_multi_asic_hld.md b/doc/multi_asic/SONiC_multi_asic_hld.md index 7587c57620..88cccdc700 100644 --- a/doc/multi_asic/SONiC_multi_asic_hld.md +++ b/doc/multi_asic/SONiC_multi_asic_hld.md @@ -525,7 +525,7 @@ Below are the list of MIBs suppored by snmp_ax_impl. |1.3.6.1.2.1.31.1 | | InterfaceMIBObjects | All namespace DBs| #### 2.4.7.2. Telemetry -There will be a single Telemetry service and telemetry docker for the multi asic platform which will pull needed data from the DB's of asic namespace. More details will be provided in a separate document. +There will be a single Telemetry service and sonic-gnmi docker for the multi asic platform which will pull needed data from the DB's of asic namespace. More details provided in [Management Framework document](https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/Management%20Framework.md). #### 2.4.7.3. LLDP diff --git a/doc/system-telemetry/dialout.md b/doc/system-telemetry/dialout.md index c2ddb7c94b..dc2368a669 100644 --- a/doc/system-telemetry/dialout.md +++ b/doc/system-telemetry/dialout.md @@ -19,7 +19,7 @@ It is useful in some scenarios. A few typical examples: # SONiC system telemetry software architecture System telemetry in SONiC supports both dial-in mode and dial-out mode. The DB client takes care of retrieving data from SONiC redis databases, while non-DB client serves data outside of redis databases. gRPC dial-out client is described in this document, -![SOFTWARE ARCHITECTURE](img/dial_in_out.png) +![SOFTWARE ARCHITECTURE](img/GNMI_Server.png) # Services provided in dialout mode gNMIDialout service is defined for telemetry in dialout mode. It has one streaming RPC: Publish. The message from client to collector reuses [SubscribeResponse](https://github.com/openconfig/gnmi/blob/f6185680be3b63e2b17e155f06bfc892f74fc3e7/proto/gnmi/gnmi.proto#L216) from gNMI spec, while the PublishResponse message is optional and skipped by default. diff --git a/doc/system-telemetry/grpc_telemetry.md b/doc/system-telemetry/grpc_telemetry.md index 78049fd23c..5a97779b6b 100644 --- a/doc/system-telemetry/grpc_telemetry.md +++ b/doc/system-telemetry/grpc_telemetry.md @@ -67,7 +67,7 @@ For data not available in DBs, Target name "OTHERS" is designated for that categ # SONiC system telemetry software architecture System telemetry in SONiC supports both dial-in mode and dial-out mode. The DB client takes care of retrieving data from SONiC redis database, while non-DB client serves data outside of redis databases. gRPC dial-in server (gNMI server) is described in this document, -![SOFTWARE ARCHITECTURE](img/dial_in_out.png) +![SOFTWARE ARCHITECTURE](img/GNMI_Server.png) # gRPC operations for system telemetry in SONiC As mentioned at the beginning, SONiC gRPC data telemetry is largely based on gNMI protocol, the GetRquest/GetResponse and SubscribeRequest/SubscribeResponse RPC have been implemented. Since SONiC doesn't have complete YANG data model yet, the DB, TABLE, KEY and Field path hierarchy is used as path to uniquely identify the configuration/state and counter data. diff --git a/doc/system-telemetry/img/GNMI_Server.png b/doc/system-telemetry/img/GNMI_Server.png new file mode 100644 index 0000000000..f5886e35f8 Binary files /dev/null and b/doc/system-telemetry/img/GNMI_Server.png differ