-
Notifications
You must be signed in to change notification settings - Fork 89
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
errors in SetResponse (proto vs. spec) #62
Comments
This is indeed a spec error, thanks for pointing it out. We'll update the spec. |
Is this spec still under development? The issue is over a year old now. I am searching for something to configure network and other devices over grpc and it would be best to not reinvent everything. So can we still expect further improvements of this document and a proper RFC? |
The specification is under active development. We did update the specification to cover some of these cases, and are continuing to work through clarifications that are needed based on completing implementations with a number of vendors. Our approach to development has been iterative, as this allows us to find real implementation issues and specification clarifications. The gNMI service is implemented on a number of major vendor's implementations (e.g., Arista, Juniper, Cisco, Ciena, Nokia, as well as a number of other in-progress or private implementations). As with all specifications during their implementation, there will be improvements as we find implementation challenges, or ambiguities across different implementations. There are now reference implementations for telemetry (in the openconfig/gnmi and the google/gnxi repositories). We have taken the approach that the document in this repo is the authoritative source of the specification for gNMI and its extension documents. The contributors have been across multiple companies. The IETF has other solutions (NETCONF, RESTCONF) - and has been somewhat hesistant to rely on third-party underlying technologies (although this issue has not been re-examined since gRPC became a CNCF project). At this time we do not have any intention to take this document into a full RFC, since it seems to constrain the community's ability to iterate on it. An RFC is not the sole mechanism of communicating a standard. If you have specific other questions -- please do let us know, and we can try and clarify. It is likely to be better to open individual issues. Thanks, |
Looking at the latest gnmi.proto, I see that Error has been deprecated, as has all its uses, including within SetResponse and UpdateResult.
However Section 3.4 still says that "In the case of a failure of an operation, the status of the UpdateResult message MUST be populated with error information as per the specification in Section 3.4.7.".
Similarly, 3.4.7 still says that we "MUST set the message field of the UpdateResult corresponding to the failed operation to an Error message indicating failure. In the case that the processed operation is not the only operation within the SetRequest the target MUST set the message field of the UpdateResult messages for all other operations, setting the code field to Aborted (10).".
I woulds image the proto is correct and the spec just hasn't been updated to agree yet - can this be clarified?
The text was updated successfully, but these errors were encountered: