Skip to content

gnoi/factory_reset: add Decommission RPC #301

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

gnoi/factory_reset: add Decommission RPC #301

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3b600de
gnoi/factory_reset: add Decommission RPC
brianneville Aug 27, 2025
81f7784
fix linter complaints
brianneville Aug 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
148 changes: 118 additions & 30 deletions factory_reset/factory_reset.pb.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

21 changes: 21 additions & 0 deletions factory_reset/factory_reset.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,27 @@ service FactoryReset {
// code INVALID_ARGUMENT must be returned with the details value set to a
// properly populated ResetError message.
rpc Start(StartRequest) returns (StartResponse);

// The Decommission RPC allows the Client to instruct the Target to
// decommission the Target and reboot.
// The Target should not boot back to the OS.
// The decommissioning process is vendor-defined, but may involves removal
// of OS images, persistent storage, licenses, and is more comprehensive
// than the Start RPC, with no options to retain anything.
// To facilitate a response being returned to the caller, the reboot
// component of this RPC is asynchronous and will run after the RPC
// has returned a DecommissionResponse.
rpc Decommission(DecommissionRequest) returns (DecommissionResponse);
Copy link
Contributor

@marcushines marcushines Sep 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not understanding the use case here
does this imply the device will actually no longer try to secure boot as well?
I am not seeing how this significantly different than just the Start with at most a new parameter?

Does this API actually have a different "caller" set which would make it at least a different auth requirement?

Copy link
Member

@samribeiro samribeiro Sep 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not augment the Start RPC instead?

}

message DecommissionRequest{
// Time (in nanoseconds) that the Target should
// wait before issuing the reboot to complete the decommission.
// If unset, the Target will assume a default of 15000000000 (15 seconds)
Copy link

@LimeHat LimeHat Sep 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How the delay is calculated?

  • from the time the target has received a request (which implies that the entire operation takes <=15 seconds by default), or
  • from the time the target completed prep. steps and is ready to undergo a reboot?

If it's the former, I'd suggest removing the fixed default value, since the procedure can require more than 15 seconds of execution on the target device.

uint64 reboot_delay = 1;
}

message DecommissionResponse{
}

message StartRequest {
Expand Down
Loading
Loading