[CONTROLLER-156] Netconf client not working Created: 12/Feb/14  Updated: 25/Jul/23  Resolved: 17/Feb/14

Status: Resolved
Project: controller
Component/s: netconf
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Reinaldo Penno Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: PC

External issue ID: 416

 Description   

Netconf client on ODL had been working fine, but after downloading the most recent distribution (today) it has stopped working and at the same time I started get the messages below and wireshark shows not Netconf packets in the network.

For reference:

http://blog.leon-rosenberg.net/2012/08/oracle-kills-getlocalhost-on-macos-x-in.html
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7180557

23:53:52,429 |-ERROR in ch.qos.logback.core.util.ContextUtil@4b636311 - Failed to get local hostname java.net.UnknownHostException: repenno-mac: repenno-mac: nodename nor servname provided, or not known
at java.net.UnknownHostException: repenno-mac: repenno-mac: nodename nor servname provided, or not known
at at java.net.InetAddress.getLocalHost(InetAddress.java:1473)
at at ch.qos.logback.core.util.ContextUtil.getLocalHostName(ContextUtil.java:32)
at at ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty(ContextUtil.java:41)
at at ch.qos.logback.classic.joran.action.ConfigurationAction.begin(ConfigurationAction.java:56)
at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:276)
at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:148)
at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:130)
at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:157)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:143)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:106)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:56)
at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75)
at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:148)
at at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85)
at at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128)
at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:107)
at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:295)
at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:269)
at at org.slf4j.LoggerFactory.ge

 Comments   
Comment by Reinaldo Penno [ 12/Feb/14 ]

How to repeat:

Copy to configuration example from https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Example_Configuration to controller.currentconfig.xml and restart ODL.

No Netconf connections will be attempted.

Comment by Tomas Olvecky [ 17/Feb/14 ]

After I left the server running for ~3 minutes I saw:
2014-02-14 16:45:51.634 CET [ConfigPersister-registrator] ERROR o.o.c.n.persist.impl.ConfigPusher - Netconf server did not provide required capabilities. Expected but not found: [urn:opendaylight:params:xml:ns:yang:controller:md:sal:dom:cluster:store?module=odl-sal-dom-clustered-store-cfg&revision=2013-10-28]

This is because odl-sal-dom-clustered-store-cfg was referenced in the XML but was not found in any running bundle. The providing bundle clustered-datastore-implementation has been disabled before hydrogen release (4e4fdfd). Since this commit the configuration is no longer valid.

It is not a blocker though, because no other config module has defined dependency on dom-clustered-store-impl. When I commented out all .cluster. nodes, configuration was loaded successfuly.

Note that this might happen in future as well: when a module is removed/refactored, the current configuration reused from previous version might no longer be valid. The preferred way is to store any additional configuration snippets in the initial folder, as separate files.

Generated at Wed Feb 07 19:52:19 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.