"Make gNOI SetBootConfig safer"

[morrowc]

Introduce a new workflow to the gNOI RPC method to SetBootConfig which permits either a rollback of the latest config which was set by explicit RPC or by failure to finalize the workflow. This workflow is similar to that which is used in the gNSI services.

An operator may want the ability to safely set a configuration and either automatically have this rollback upon failure, or request a rollback of the last change. This functionality is available in many vendor CLI today in the form of commit confirmed or similar syntax. Growing the gNOI interface to support this for SetBootConfig should enable safer operations.

[LimeHat]

I see this has been merged via #336 , but there are several items that aren't entirely clear from reading the spec.

1. persistence: is the new config persistent before the finalizeRequest is received?
2. should parallel config changes be blocked until the SetBootConfigVerified RPC completes (with either the finalize or rollback action)? If block is required, does that include all mgmt interfaces (such as gnmi)?
3. non-config fields: the SetBootConfigRequest message includes multiple fields unrelated to the config, such as gnsi authz/certz/pathz data. Do you expect to support rotating this data through the Verified RPC as well?
4. The spec doesn't specify any explicit timeouts - does this imply the system could remain in the "pending" state indefinitely as long as the gRPC connection stays alive?
   • Wouldn't this be problematic if a client loses its connection (e.g. due to a new ACL rule or static route), but the session lingers until the keepalive timer expires (which might be quite long)?

cc @robshakir

[morrowc]

I like your questions! these seem like ... :( problems we should address!

Do you want to propose edits to the text in the proto?

I don't, though, get your point about pathz / gnsi? what exactly is that? (I think more words or more context in your question is required for me to understand your point)

[morrowc]

@LimeHat beep