-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add gNOI Reboot HLD. #1489
base: master
Are you sure you want to change the base?
Add gNOI Reboot HLD. #1489
Conversation
|
||
## Architecture Design | ||
|
||
The proposal is to create a Reboot Backend (BE) daemon in a new “Framework” container to handle a reboot request and forward it to the platform via DBUS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this backend daemon? Can we use GNOI server to invoke DBUS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#1485 proposes daemonizing the warm-boot orchestration and thus will be the backend for warm-boot requests. Additionally, we want a common backend daemon for all types of reboots (cold, warm etc.). If we don't have this daemon then gNOI server would need to figure out the back-end based on the reboot request type. In my opinion, having a common backend provides a cleaner architecture, hence this backend daemon has been proposed.
|
||
|
||
|
||
* system reboot (method = warm, cold, fast, etc) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you detailed the reboot design for all the methods? There is no straightforward mapping between these methods with gNOI enum RebootMethod. We prposed below mapping:
enum RebootMethod {
UNKNOWN = 0; // Invalid default method.
COLD = 1; // Shutdown and restart OS and all hardware.
POWERDOWN = 2; // Halt and power down, if possible.
HALT = 3; // Halt, if possible.
WARM = 4; // Reload configuration but not underlying hardware.
NSF = 5; // Non-stop-forwarding reboot, if possible.
// RESET method is deprecated in favor of the gNOI FactoryReset.Start().
reserved 6;
POWERUP = 7; // Apply power, no-op if power is already on.
}
For SONiC cold reboot, we can use COLD method.
For SONiC warm reboot, we can use WARM method.
For SONiC fast reboot, we can use NSF method.
For SONiC config reload, we can use reserved method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure why WARM and NSF reboot methods are defined separately in the gNOI spec. In my opinion they both refer to the same operation. I would propose adding a new reboot method for fast reboot since it doesn't map to any of the current gNOI reboot methods.
Initial draft of gNOI Reboot HLD.