-
Notifications
You must be signed in to change notification settings - Fork 197
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
commit confirmed #154
commit confirmed #154
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,6 +21,8 @@ syntax = "proto3"; | |
// extensions defined outside of this package. | ||
package gnmi_ext; | ||
|
||
import "google/protobuf/duration.proto"; | ||
|
||
option go_package = "github.com/openconfig/gnmi/proto/gnmi_ext"; | ||
|
||
// The Extension message contains a single gNMI extension. | ||
|
@@ -30,6 +32,7 @@ message Extension { | |
// Well known extensions. | ||
MasterArbitration master_arbitration = 2; // Master arbitration extension. | ||
History history = 3; // History extension. | ||
CommitConfirmed commit_confirmed = 4; // Commit Confirmed extension. | ||
} | ||
} | ||
|
||
|
@@ -89,3 +92,47 @@ message TimeRange { | |
int64 start = 1; // Nanoseconds since the epoch | ||
int64 end = 2; // Nanoseconds since the epoch | ||
} | ||
|
||
// The CommitID is returned by the gNMI server to indicate the ID of a commit. | ||
// It is returned in response to the Set Request with the CommitConfirm message | ||
// that had COMMIT_CONFIRMED_ACTION_START set. | ||
// The CommitID is used in the subsequent SetRequest/CommitConfirm messages | ||
// to identify commit to be confirmed, reset or rejected. | ||
message CommitID { | ||
string id = 1; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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 commentThe reason will be displayed to describe this comment to others. Learn more.
Are you intending this to be a pseudo-transaction blocking all other users/sessions from committing while this commit is validated? If so I think perhaps you should rename _START to _START_W_LOCK to capture that semantic. (This then narrows down the use-case for using this extension to one where all requests are funnelled through one agent, or all agents can handle being queued...) Although it would be possible to enable other commits to continue, it then leaves a question of what to do on timeout/reject, because other commits may have overlapped with this one and an 'undo' of this commit may not leave a valid system state any more. I suspect this mode would be problematic to define. Is your use-case the 'W_LOCK' case? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The proposed commit-confirmed workflow assumes that once the commit-confirmed started, the lock is put in place preventing any other commits from happening. Any subsequent SetRequest without commit-confirmed extension (a regular SetRequest) will yield an error. This is not explained in openconfig/reference#198 and you made a great point that it needs to be clarified. Because no parallel commit-confirmed are allowed, it is implicitly assumed that the running datastore is locked for any other commits until the commit in question is confirmed or rejected There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great - yes please clarify in the document, but also I think it would be better to make this explict here with the action names or at least the comments next to the action names: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will defer for now and wait for OC/Google comments on this PR since it can be that they would like to proceed with their version which is in #155 |
||
} | ||
|
||
// The CommitConfirmed allows automatic rollback of a commit | ||
// if Set changes are not confirmed within the specified timeout. | ||
// The document about gNMI commit confirmed can be found at | ||
// https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-commit-confirmed.md | ||
hellt marked this conversation as resolved.
Show resolved
Hide resolved
|
||
message CommitConfirmed { | ||
CommitConfirmedAction action = 1; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the rational behind defining action as an enum over what is proposed in openconfig/reference#197 which is to use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @kidiyoor this is subjective, but it feels more natural to the way users approach commit confirmation via the CLI/Netconf. When I see commit_id, confirm_id, cancel_id it somehow feels that these may be different IDs, though my understanding is that we don't have vendor implementation which support multiple parallel commits. Since actions are contained within the ENUM you have the same proto-guarded behavior when only a single action can be present. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To eliminate confusion of the spec appearing to use different IDs - I have updated the I believe that using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @kidiyoor @dplore I think one of the fundamental differences between #154 and #155 is that in our proposal, the This matched our implementation on both platforms (SR Linux and SR OS), and I feel like this is also true for most other NOSes that currently support commit operations. I just noticed that @kidiyoor commented about point 1 here #154 (comment) From our standpoint we can also work with client-selected IDs (like it is done in netconf), so it seems we just need to converge which way to go with the commit-confirmed. |
||
// rollback timeout duration expressed in seconds and nanoseconds. | ||
// If timeout is not set (or seconds and ns are both 0), then | ||
// the default gNMI server's rollback timeout duration is used. | ||
google.protobuf.Duration timeout = 2; | ||
// CommitID from commit for ACCEPT or REJECT | ||
CommitID commit_id = 3; | ||
} | ||
|
||
// A COMMIT_CONFIRMED_ACTION_START starts a commit with a configured rollback | ||
// timeout and will return the CommitID assigned by the server. The CommitID is | ||
// used to identify the current commit. The COMMIT_CONFIRMED_ACTION_CONFIRM and | ||
// COMMIT_CONFIRMED_ACTION_REJECT confirms or cancels a commit using the | ||
// commit_id. | ||
enum CommitConfirmedAction { | ||
// gNMI server should return InvalidArgument error if the action is not | ||
// specified for a CommitConfirmed extension. | ||
COMMIT_CONFIRMED_ACTION_UNSPECIFIED = 0; | ||
// Starts a commit with a specified rollback timeout | ||
// or resets the timeout for the commit that has confirmation pending. | ||
COMMIT_CONFIRMED_ACTION_START = 1; | ||
// Confirm a commit identified by CommitID. | ||
COMMIT_CONFIRMED_ACTION_CONFIRM = 2; | ||
// Reject and rollback a commit identified by CommitID | ||
// for which rollback timeout has not expired. | ||
// If no active commit with the non expired rollback timeout is found, | ||
// gNMI server should return InvalidArgument error. | ||
COMMIT_CONFIRMED_ACTION_REJECT = 3; | ||
} |
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.
Is the intention that this is only used on the end of a SetRequest, with the START message an Extension of the original Set that needs confirmation?
How are the REJECT/COMMIT sent in? Is it a follow-up SetRequest with just the origin (& target) set (plus the CommitConfirmed msg). Is it valid to enforce in the server that there is no actual data to set in the message (i.e. its just a wrapper for conveying the next steps in handling a previous SetRequest), or is it expected that a CommitConfirm for a previous SetRequest could be updated in an independent SetRequest?
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.
This is common to any extension.
Rejects and Confirms are sent within the SetRequest message.
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.
Thanks - is also clear in the linked .md you referenced