-
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
Add commit confirmed extension to SetRequest #196
Conversation
Hi @kidiyoor |
@hellt yes, the goal is to converge on the extension. You can find the proto in the proposed md file. Could you share how you r custom extension look like ? |
@kidiyoor yes, we would like to collaborate on this one. I will have to gather some details internally before pasting our extension proto. |
A few initial comments (will just lump here vs. inline) as we start to breach upon more reinvention of long standing features from other well-defined protocols.
In reality, gNMI Set() abstracts out important distinct transactional operations that the NETCONF world has had for some time. These operations have been part of operational workflows for some time (whether good or bad) and while this may introduce back a feature from this world, other gating factors for various operators have also been |
Ebben -- whilst I'm sympathetic to "some operators might need additional things", all of the OpenConfig work (and I'd say open source contributions in general) are going to be driven by a use case that exists today. If these operators that want to have a wider transactional framework in gNMI (which I'm unsure that I personally am supportive of, for the record), then can we go ahead and discuss that in the context of their use cases -- along with contributions that move this forward please? I'm not clear that deviations from 6241 are a first-class problem -- these are different protocols with different designs. Implementation decisions that cause operational overhead/problems, and/or cannot be implemented in shipping implementations are more of concern. I do not consider "we baked this in an RFC" as a yardstick for excellent (or even implementable) technical design. w.r.t the specific question of "why an extension?". Practically, it is extremely complex for us to keep a single specification that describes everything in gNMI. Extensions allow the protocol to be extended in a manner that allows new use cases to be covered that aren't necessarily relevant to all implementations (see master election for another example). On top of that, it allows us to provide subsets of the protocol that can be described in more constrained specifications. Practically, my preference is to extend gNMI primarily via extensions going forward. In some cases, this isn't possible (see thx, |
+1 on extension being the primary way to update the gNMI proto. The base gNMI proto should be considered a minimum implementation. With extensions we create additional features that are in addition to the base proto. The target for this extension is to be a well known extension Regarding the requirements for the |
From Nokia perspective I am aiming to post our proposal and implementation example next week. Will do this as a PR against the current master branch for an easier review process |
I think there is a misunderstanding of my point. My point is not a blind comparison to an RFC but rather drawing reference to existing standards, implementations and architectures that have been shipping for years since a majority of this work is reinventing the wheel often coming in reverse but choosing to deviate without clear reason. IMO when reinventing the wheel, there should be an understanding of history, existing implementations and clear problem statements followed with proper justification as to the reason why a prior technology cannot suffice. The concept in this PR is the same from prior technologies but there is a choice to change some behaviors in a less efficient fashion and that is what I am challenging here is all. You can choose to align to other like technologies or not but let's get some good reasoning behind such. A PR without description or prior reference is also not a good justification. Many implementations will support all prior technologies concurrently thus obvious, the more alignment, the more likelyhood of desired outcomes. Any misalignment is new implementation which is fine but should be justified with an understanding of co-existance. |
Above comments already address why this should be an extension over modifications to the core. The initial proposal did deviate from the RFC, as I was not aware of its existence. It makes sense to align with the RFC as much as possible. I have incorporated most of feedbacks and created a new proposal #197. We can probably continue discuss about the open questions in the new issue. |
Hi all, The main differences from the proposal in #196 and #197 is the usage of We also used a set of actions, expressed as an enum to indicate the procedure call to use. |
Updating the proposal as per the Proposal-1 of in [openconfig#197](openconfig#197)
Moving rollback_duration inside *CommitRequest* action eliminates wrong client usage of passing rollback_duration during confirm or cancel call.
I believe the reference should be more verbose. Maybe a good idea to look at #198 and try to minimize potential uncertainties by clarifying the exact workflows/call_flows expected. |
No description provided.