sonic-host-services changes for gNOI Warm Reboot #191
Conversation
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
e42ae0a to
76f70db
Compare
|
@github76543 Joh, can you PTAL and signoff. |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
2 times, most recently
from
a230e6e to
f71371e
Compare
Thanks @hdwhdw for the reference. The reboot dbus service also needs a request/response framework which is what this PR does and IIUC @vvolam went with the other one as a stop gap solution. Adding @github76543 (John) for additional inputs. |
|
@kishanps thanks for clarifying. If so consider renaming the service to something more general than gnoi_reboot. Maybe 'async_system'? Having one module for each gnoi service can clutter the dbus codebase. Also does it make sense to add your api to systemd service and call it async reboot, alongside @vvolam API? |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
f71371e to
12e3f91
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
@hdwhdw @github76543 @rkavitha-hcl @jaanah-hcl I discussed with John, Dawei Huang & @vvolam and we all agree that reboot will be a separate dbus service and hence rename gnoi_reboot to just reboot. And remove the commit id ff73070 alongwith this PR to avoid the duplication. |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
12e3f91 to
f568f97
Compare
|
/azp run |
|
Pull request contains merge conflicts. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
2f86ace to
24b587c
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
24b587c to
61e547d
Compare
|
/azp run |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| "stderr: %s", MOD_NAME, stdout, stderr) | ||
| return | ||
|
|
||
| """Wait for the reboot to complete. Here, we expect that SONiC Host Service |
There was a problem hiding this comment.
I just realized this check!!
This check is wrong for HALT method, in case of HALT, gnmi container will be alive and only pmon and syncd containers will be killed for now. Can we modify the logic accordingly to below logic?
Just wait for 30 or 60 secs timeout and if pmon container is not killed, HALT method is failed.
There was a problem hiding this comment.
@vvolam I suppose the reboot -p will keep gnmi and bring down all other containers. In that case, should we just ensure that gnmi is the only container up in case of HALT ? Maybe keep the timeout the same to take care of other use cases where more containers need to be brought down.
There was a problem hiding this comment.
@kishanps Yes, we can do that because we always ensure gnmi container is up in case of HALT.
There was a problem hiding this comment.
@rkavitha-hcl could you fix this check for HALT case, as the gnmi container will still be running?
There was a problem hiding this comment.
Kavitha is out sick, @jaanah-hcl Can you pls take care of this.
There was a problem hiding this comment.
@vvolam One more question on reboot -p, does it keep framework container also up along with gnmi container ? Don't you need framework container for the reboot status after the HALT execution ?
There was a problem hiding this comment.
@kishanps As I mentioned, it only kills syncd and pmon containers as of now and all remaining containers stay up.
There was a problem hiding this comment.
There are 2 parts here
- What are the containers you want to kill ? For smartswitch, pmon & syncd may suffice but if its a regular switch you probably need to kill other running containers also. In which case, you may want to kill all containers except gnmi & framework (tied to the next part)
- Do you need framework container after HALT to query reboot status ? I don't know the use-case of HALT, so you may be the better person to call on that. If you intend to make reboot status call, then you need framework container also to give you back the status.
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
5e20b72 to
99ede2f
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@kishanps @rkavitha-hcl Could you fix build failures as well? |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
99ede2f to
7eb5420
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Build is fixed and branch is rebased |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
7eb5420 to
4e4a719
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
4e4a719 to
f24657e
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
f24657e to
e60d9f2
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
rkavitha-hcl
force-pushed
the
gnoi_wr_hs_new
branch
from
e60d9f2 to
9872013
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Adding sonic-host-services changes for warm reboot .
Adding HALT method support for sonic-host-services