[NETCONF-85] Inconsistent COMMIT operation handling when no transactions are present Created: 12/Oct/15 Updated: 15/Mar/19 Resolved: 25/Feb/16 |
|
| Status: | Resolved |
| Project: | netconf |
| Component/s: | netconf |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Jozef Behran | Assignee: | Jakub Morvay |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 4455 |
| Description |
|
When the COMMIT RPC operation is requested and the "candidate" configuration does not differ from the "running" configuration, the following error is usually reported: <rpc-reply message-id="MMMM" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> However when an operation was attempted and the operation fails (such as attempting to delete a nonexistent node), the commit will succeed but it shall fail. This fake success will repeat even when the commit operation is attempted again immediately. To hit the bug, run freshly extracted ODL, open a NETCONF connection, send the "hello" message (I don't know how to do that from a bash shell script, I always get "java.lang.IllegalArgumentException: Additional header in wrong format [admin;0:0:0:0:0:0:0:1:56415;ssh;client;], expected [(<username>[^;]);(?<address>[0-9\.])[:/](?<port>[0-9]);(?<transport>[a-z])[^\]]+]" after sending my "hello" message, the only way that works for me is using this suite in Gerrit: https://git.opendaylight.org/gerrit/27672, it reports one test failure with reference to this bug) and then send the following (the important thing is that it shall have no <modules> element in its running configuration when you try to do this, use "<get-config><source><running/></source></get-config>" RPC request to verify that) (also beware, the requests here are NOT tested, the correct ones are in the Gerrit change just mentioned): <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> You will obtain: <?xml version="1.0" encoding="UTF-8" standalone="no"?> Note that the second and third messages are wrong, they should be: <rpc-reply message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> |
| Comments |
| Comment by Jakub Morvay [ 14/Jan/16 ] |
|
According to netconf specification, specifically specification of candidate configuration capability https://tools.ietf.org/html/rfc6241#section-8.3, commit operation effectively sets the running configuration to the current contents of the candidate configuration. So even if the candidate configuration is not different from running configuration, specification does not say that commit should fail. You can edit candidate configuration with edit-config operations and if one of them fails, specification does not say that commit should fail. Another question is why commits without prior edit-config operations fail with error message: Netconf specification does not mention notion of transactions, so maybe we should just return positive response: |
| Comment by Jakub Morvay [ 14/Jan/16 ] |
|
Patches for config subsystem netconf northbound Patch for md-sal netconf northbound |
| Comment by Jakub Morvay [ 19/Jan/16 ] |
|
Patches for berrylium: Patches for config subsystem netconf northbound: Patch for netconf md-sal northbound: |
| Comment by Jozef Behran [ 18/Feb/16 ] |
|
Need to cherry-pick the patches to Lithium stable as well. See https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-1node-userfeatures-all-stable-lithium/86/robot/report/log.html#s1-s2-s1-t18 for an example of a failure. |
| Comment by Tomas Cere [ 25/Feb/16 ] |