Is it platform specific
generic
Importance or Severity
Medium
Description of the enhancement
gNMI accepts SET requests with a full config delete and full config update, and treats that as a full config reload. This used to be implemented internally to gNMI. The config would be written to a temp file locally in the gNMI container, and when a Reboot was triggered a config reload would be called on that file. Recent changes have been made to implement Reboot at the system level, and this approach no longer works. The sonic-mgmt test case has been disabled, and this functionality has effectively been dropped.
There is a D-Bus endpoint for ConfigReload, so it would be easy to trigger it directly and decouple it from Reboot entirely. But since ConfigReload brings down all services it causes gNMI to restart, which kills the connection. This could be accounted for by building in a callback mechanism which replies to the calling client and then closes the listing socket, and only then calls ConfigReload. This is roughly in line with the current implementation, except for using a real ConfigReload and not requiring the user to trigger it on their own.
We expect minimal disruption as the command is currently non-functional, so any users will have breaking upstream changes as it is.
Current Behavior
Currently, this command is not functional.
Proposed Behavior
Sending a gNMI SET-UPDATE with a full config delete path and a full config update path will trigger a call to ConfigReload(), causing configuration to be reloaded immediately. The request will be returned to the user and the gNMI server will be shut down before finally triggering ConfigReload.
Is it platform specific
generic
Importance or Severity
Medium
Description of the enhancement
gNMI accepts SET requests with a full config delete and full config update, and treats that as a full config reload. This used to be implemented internally to gNMI. The config would be written to a temp file locally in the gNMI container, and when a Reboot was triggered a
config reloadwould be called on that file. Recent changes have been made to implement Reboot at the system level, and this approach no longer works. The sonic-mgmt test case has been disabled, and this functionality has effectively been dropped.There is a D-Bus endpoint for ConfigReload, so it would be easy to trigger it directly and decouple it from Reboot entirely. But since ConfigReload brings down all services it causes gNMI to restart, which kills the connection. This could be accounted for by building in a callback mechanism which replies to the calling client and then closes the listing socket, and only then calls ConfigReload. This is roughly in line with the current implementation, except for using a real ConfigReload and not requiring the user to trigger it on their own.
We expect minimal disruption as the command is currently non-functional, so any users will have breaking upstream changes as it is.
Current Behavior
Currently, this command is not functional.
Proposed Behavior
Sending a gNMI SET-UPDATE with a full config delete path and a full config update path will trigger a call to ConfigReload(), causing configuration to be reloaded immediately. The request will be returned to the user and the gNMI server will be shut down before finally triggering ConfigReload.