Update Reboot proto

[xw-g]

Propose to:

• Clarify the behavior when the list of subcomponents is not set.
• Because RebootStatusRequest supports a list of subcomponents, the RebootStatusResponse should also have a way to identify status per subcomponent.

Another option is to deprecate the list of subcomponents in all reboot related proto, and only allow the request to target a single subcomponent. But then it raises more questions, like:

• Can the single subcomponent be an optional field?
• If it can be an optional field, what the default behavior if it's not set?
• If the default behavior is to apply to the whole device (including all subcomponents), then any status reports should also be per component anyway.

[xw-g]

@marcushines to review.

[coveralls]

Pull Request Test Coverage Report for Build 3160674502

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 0.0%

---

Totals
Change from base Build 3093533408:	0.0%
Covered Lines:	0
Relevant Lines:	0

---

💛 - Coveralls

[xw-g]

This will probably impact the following merged PRs:

• https://github.com/openconfig/featureprofiles/pull/281
• https://github.com/openconfig/featureprofiles/pull/124

[hellt]

Hi all, Since this PR is targeting the Reboot RPC, I would like to clarify what is the common thinking for the RebootResponse when you reboot the active CPM or the whole chassis.

If gNOI server runs on CPM_A, then what is expected of a system when you reboot this CPM or the whole chassis? Should the response be sent back before the component goes for a reboot? or should it just go for a reboot which results in a TCP session to break?

/cc @marcushines

[rgwilton]

If the concern is about accidentally rebooting a chassis, as opposed to a linecard, then perhaps the simplest thing to do would be to split these into two separate reboot RPC operations?

E.g., RebootEntireDevice and RebootSubComponent?

I'm also not sure that I see a great reason to allow multiple components to be rebooted in a single RPC, generally rebooting stuff should be pretty rare and not performance critical.

[xw-g]

Internal bug b/245550570.

[LimeHat]

@dplore I'm curious, is there a plan to move this PR forward? Been stale for almost a year.

[dplore]

It's been pushed out for some time. I have queued it in my sprint plan, but currently is about 3 weeks out for review/refactoring.