SONiC Configuration Replace - High Level Design #571
Conversation
Signed-off-by: Rajendra Dendukuri <rajendra.dendukuri@broadcom.com>
Signed-off-by: Rajendra Dendukuri <rajendra.dendukuri@broadcom.com>
|
Usage of configlet command could simplify as it could take list of JSON objects and it would apply them in the given order. The good thing is that they still go through ConfigDB connector, hence the same central point which is used on any update. |
The plan is to use the jsonpatch py library to find a diff. Can you please provide a reference to the configlet command mentioned. https://pypi.org/project/jsonpatch/ The sonic-py-swsssdk is then used to generate updates to the ConfigDB. |
|
|
||
|
|
||
|
|
||
| The ConfigDB JSON patch file is a list of elements which contain following fields. Each element results in one or more ConfigDB updates. For detailed information about the JSON patch operations refer to the section 4(Operations) of [RFC 6902](https://tools.ietf.org/html/rfc6902). |
There was a problem hiding this comment.
Can it possible to define a config replace contract so that all the features must implement it wihtout miss it. The contract could be the steps pre/depency graph/config-replace/post/corrective action/enable or disable.
| #### ConfigDB Table Update Sync | ||
|
|
||
|
|
||
| In order to serialize the processing of ConfigDB updates, the ConfigDB patch apply operation has to wait for a confirmation from the application that all ConfigDB table updates have been processed. Only after that it can move to next table. For each table, a special key *sync* is introduced which is used as a marker on which the patch apply process waits for. When the consumer process of TABLE_A receives set operation with key value as sync, it deletes the "TABLE_A|sync" row from the ConfigDB. The patch apply process, after issuing all ConfigDB update commands, creates a table row "TABLE_A|sync" and waits for 30 seconds for the row entry to be deleted by the application. If the sync entry is not deleted by application even after 30 seconds, it logs an error and performs the fail-safe action. The wait time of 30 seconds is user configurable and can be provided as an argument to the *config replace* command. Optionally, the *config replace* can continue to process the next patch operation after logging the error if the *best-effort* option is selected by the user. |
There was a problem hiding this comment.
Will it be possible to extend SYNC flag support at attribute level?
| |6|Remove an item form an array value.| | ||
| |7|Add a new key to an existing table.| | ||
| |8|Remove a key from an existing table.| | ||
| |9|Replace the switch configuration from a simple configuration to a configuration file with huge configuration difference. Use maximum number of VLANs and ports to create a huge configuration.| |
There was a problem hiding this comment.
Is there any performance impact /downtime while using config replace on day to day operations under traffic? List out if you have any suggestions to use it right?
Here you go for SONiC configLet - https://github.com/Azure/sonic-utilities/blob/master/scripts/configlet. |
yxieca
force-pushed
the
master
branch
2 times, most recently
from
8498931
to
8837dc2
Compare
No description provided.