compute0-karaf.zip
|
Duplicate |
|||
| is duplicated by |
|
Netconf CRUD suite uses add-netconf-n... | Resolved |
[NETCONF-456] Honeycomb mounting sometimes fails in Oxygen Created: 23/Aug/17 Updated: 15/Mar/19 Resolved: 25/Sep/17 |
|
| Status: | Resolved |
| Project: | netconf |
| Component/s: | netconf |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Juraj Linkeš | Assignee: | Tomas Cere |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: Linux |
||
| Attachments: |
compute0-karaf.zip
|
||||||||
| Issue Links: |
|
||||||||
| External issue ID: | 9033 | ||||||||
| Description |
|
This doesn't happen everytime. The environment is Oxygen three node cluster. Node mount configuration: { "netconf-node-topology:between-attempts-timeout-millis": 10000, "netconf-node-topology:connection-timeout-millis": 10000, "netconf-node-topology:default-request-timeout-millis": 10000, "netconf-node-topology:host": "192.168.10.26", "netconf-node-topology:keepalive-delay": 0, "netconf-node-topology:max-connection-attempts": 10, "netconf-node-topology:password": "HBfU1gKHExw89lMB3juq1g==", "netconf-node-topology:port": 2831, "netconf-node-topology:tcp-only": false, "netconf-node-topology:username": "HBfU1gKHExw89lMB3juq1g==", "node-id": "overcloud-novacompute-0.opnfv.org" }Attached log corresponds to one of our nodes being stuck in connecting state: ' | head -1):8081/restconf/operational/network-topology:network-topology/ | python -mjson.tool | grep netconf-node-topology:connection-status -A 4 |
| Comments |
| Comment by Juraj Linkeš [ 23/Aug/17 ] |
|
Attachment compute0-karaf.zip has been added with description: karaf log |
| Comment by Jakub Morvay [ 24/Aug/17 ] |
|
First of all, I have to mention that this issue only with clustered netconf topology. This seems to be related to patch https://git.opendaylight.org/gerrit/#/c/52528/. This patch introduced netconf mountpoints credentials encryption. Now, I won't go into detail how does this credentials encryption exactly work, I have already described it in The problem is this second DS write of netconf node config with encrypted credentials into netconf-topology. This triggers the reconfiguration of netconf node mountpoint. In the case that mountpoint has not been properly initialized, this reconfiguration can cause some problems. I think it's issue with some incorrect resource cleanup after disconnecting the old connection and closing the sal facade as a first step of reconfiguration process. |
| Comment by Kit Lou [ 05/Sep/17 ] |
|
Is this a blocker for nitrogen? Please confirm. Thanks! |
| Comment by Juraj Linkeš [ 06/Sep/17 ] |
|
Yes, it is a blocker for Nitrogen. |
| Comment by Jakub Morvay [ 06/Sep/17 ] |
|
There is some discrepancy between stable/nitrogen and stable/carbon branches. We have to cherry-pick some patches to nitrogen (and master) so we will end up in the same state regarding the credentials encryption as in carbon. There was a consensus that we should not automatically encrypt mountpoint's credentials because it triggers the problematic second data tree change event. So the original patch that introduced it was reverted in carbon. Cherry-pick to nitrogen: To allow users to encrypt mountpoint's credentials, new add-netconf-node RPC is introduced. This RPC does not issue problematic second write of the same netconf node to DS, so this approach does not suffer from the issues the original approach suffers from. Cherry-picks to nitrogen: The first patch actually introduces SSH public key authentication to netconf southbound. We need this patch to avoid complex cherry-pick of the second patch (that is actual add-netconf-node RPC), because it depends on some functionality the first patch introduces. Anyway, the public key authentication is present on Carbon and should be present also on Nitrogen. We also depends on some util stuff from AAA project and we need to port that util stuff to Nitrogen too. Cherry-pick to nitrogen: With all of this in nitrogen, the bug should not be present anymore. There will be no automatic second writes to DS for each new netconf node, so there won't be no reconnects during mountpoints creation. However, we can still hit this when application or user will try to write the same node to netconf-topology multiple times in short time. I am going to open a new bug for that, since that is not blocker and does not happen automatically on our side with each new netconf node as this bug itself. |
| Comment by Jakub Morvay [ 06/Sep/17 ] |
|
The patches are in Nitrogen already. We have to cherry-pick them also to Oxygen. |
| Comment by Tomas Cere [ 25/Sep/17 ] |
|
All cherry-picks should be in Oxygen now |