From: Jan Srnicek -X (jsrnicek - PANTHEON TECHNOLOGIES at Cisco)
Sent: 13 lutego 2017 09:08
To: Yang, Yi Y <yi.y.yang@...>; Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgradzki@...>; 'honeycomb-dev@...' <honeycomb-dev@...>
Cc: Srihari Raghavan (srihari) <srihari@...>
Subject: RE: [honeycomb-dev] Anybody knows why I got this error when I was adding a bridgedomain

 

Forgot to mention

 

For hc2vpp ,it must be bild with https://gerrit.fd.io/r/#/c/5065

 

 

 

Hi ,

 

I’ve been finally able to reproduce your behaviour. From my testing it looks like its related to newer ODL  versions,

that’ve bumped to recently. It would be great if you can verify this.

 

Here is patch that downgrades ODL depencencies  - https://gerrit.fd.io/r/#/c/5064/

 

You will need to build honeycomb and hc2vpp manually

 

For honeycomb

 

git clone http://gerrit.fd.io/r/honeycomb && cd honeycomb

git fetch https://gerrit.fd.io/r/honeycomb refs/changes/64/5064/3 && git checkout FETCH_HEAD

mvn clean install –DskipTests

 

For hc2vpp

 

Git clone http://gerrit.fd.io/r/hc2vpp && cd hc2vpp

mvn clean install –DskipTests

 

Run

 

Cd hc2vpp/vpp-integration/minimal-distribution/target/vpp-integration-distribution-1.17.04-SNAPSHOT-hc/vpp-integration-distribution-1.17.04-SNAPSHOT$

Sudo ./honeycomb

 

If my testing conclusions were right, this should remove your issue. Bare in mind that this is just experimental change,(know about one error from

Lisp plugin ,that will be shown on start). We will introduce official changes to take care of this issue soon

 

 

 

 

I did workaround in ODL SFC source code, it puts the below into honeycomb node firstly.

 

{

    "bridge-domains": {

        "bridge-domain": [

            {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

    }

}

 

Then I add bridge domain by the below

 

  {

        "bridge-domain": [

            {

                "name": "SFCVPP",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

 

        ]

    }

 

Error log in ODL, this is from honeycomb’s reply, so honeycomb has the same log.

 

       | 302 - org.opendaylight.netconf.sal-netconf-connector - 1.5.0.SNAPSHOT | RemoteDevice{SFF1}: Error reply from remote device, request: <rpc message-id="m-3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<commit/>

</rpc>

, response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-3">

<rpc-error>

<error-type>application</error-type>

<error-tag>operation-failed</error-tag>

<error-severity>error</error-severity>

<error-message>Unexpected error</error-message>

<error-info>

<error>java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}], modificationType=WRITE, childModification={}]}]</error>

</error-info>

</rpc-error>

</rpc-reply>

 

NetconfDocumentedException{message=Unexpected error, errorType=APPLICATION, errorTag=OPERATION_FAILED, errorSeverity=ERROR, errorInfo={error=java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}], modificationType=WRITE, childModification={}]}]}}

        at org.opendaylight.netconf.api.NetconfDocumentedException.fromXMLDocument(NetconfDocumentedException.java:46)

        at org.opendaylight.netconf.sal.connect.netconf.util.NetconfMessageTransformUtil.checkSuccessReply(NetconfMessageTransformUtil.java:206)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.processMessage(NetconfDeviceCommunicator.java:314)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:262)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:49)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:64)[296:org.opendaylight.netconf.netty-util:1.2.0.SNAPSHOT]

        at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:35)[296:org.opendaylight.netconf.netty-util:1.2.0.SNAPSHOT]

        at org.opendaylight.protocol.framework.AbstractProtocolSession.channelRead0(AbstractProtocolSession.java:53)[285:org.opendaylight.controller.protocol-framework:0.9.0.SNAPSHOT]

        at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)[141:io.netty.codec:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)[141:io.netty.codec:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)[141:io.netty.codec:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)[141:io.netty.codec:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1280)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:890)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:564)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:505)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:419)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:391)[140:io.netty.transport:4.0.37.Final]

        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[139:io.netty.common:4.0.37.Final]

        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)[139:io.netty.common:4.0.37.Final]

        at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]

2017-01-23 17:29:38,687 | WARN  | oupCloseable-3-2 | NetconfRpcFutureCallback

 

 

Please describe me exactly requests for the workaround.

Also please attach honeycomb logs for both cases (failure without workaround, success with workaround).

 

Thanks,

Marek

 

 

Direct invoke is ok, but it is not ok by ODL. The same ODL can work in honeycomb 16.09. in honeycomb 17.01, I can work around this issue by putting bridgedomains with one dummy entry first in ODL.

 

 

Request looks fine, please try to invoke that directly (without ODL – don’t know exactly what your ODL app is doing).

 

Thanks,

Marek

 

 

PUT http://10.240.224.185:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/CLASSIFIER1/yang-ext:mount/v3po:vpp/bridge-domains/bridge-domain/testBD2

 

{

    "bridge-domain": [

        {

            "name": "testBD2",

            "flood": "true",

            "forward": "false",

            "learn": "false",

            "unknown-unicast-flood": "false",

            "arp-termination": "false"

        }

    ]

}

 

The result is

 

{

    "errors": {

        "error": [

            {

                "error-type": "application",

                "error-tag": "operation-failed",

                "error-message": "Problem while PUT operations"

            }

        ]

    }

}

 

 

Sorry, still don’t quite understand, especially the part

“one bridge-domain in list bridge-domains, at the beginning, list bridge-domains doesn’t exist in config data store”

 

Just checked that creating and adding BDs to existing ones work for me. So please explain what requests (url + content) you are

sending step by step (including get to show what is your initial configuration).

 

Regards,

Marek

 

 

 

Marek, one bridge-domain in list bridge-domains, at the beginning, list bridge-domains doesn’t exist in config data store, so you will fail to add a bridge-domain to bridge-domains. This is the issue.

 

{

    "bridge-domains": {

        "bridge-domain": [

            {

                "name": "SFCVPP",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            },

            {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

    }

}

 

 

Please describe one more time what you are trying to do.

You want to add  one bd, then another?

 

Regards,

Marek

 

 

It can’t succeed for ever if no bridgedomains is there.

 

 

Hi,

 

Not sure if I understand your issue. If you target your request at bridge domains node, then you affect all bridge domains,

If you want to add more, then either put then all in the new request or target bridge-domain node:

 

PUT http://localhost:8183/restconf/config/v3po:vpp/bridge-domains/bridge-domain/SFCDUMMY

{

        "bridge-domain": [

              {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

}

 

Regards,

Marek

 

 

Hi, Marek

 

I’m not sure if you received this email, so I resend it.

 

I think this is really a honeycomb issue, at the beginning, in honeycomb config data store, we can’t get bridgedomains because it doesn’t exist, but honeycomb will report error because bridgedomains don’t exist when I add a bridge domain, I can successfully create an empty bridgedomains

 

{

    "bridge-domains": {

  }

}

 

but I can’t get bridgedomains after that because honeycomb think empty means it shouldn’t exist, the behavior in previous honeycomb version isn’t so.

 

In current version, how can I add a bridgedomain successfully? I need to create bridgedomains including one entry, it looks like this

 

{

    "bridge-domains": {

        "bridge-domain": [

              {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

    }

}

 

Then I can add a new bridgedomain, bridgedomains will disappear when I removed all the bridgedomain entry.

 

So I only can create bridgedomains including a dummy bridgedomain entry beforehand in order that a new add operation can work, this is really unreasonable, I hope you can have a fix patch to correct this misbehavior.

 

The issue is same for nsh entries and nsh maps, I think this should be a common issue for all the list nodes in honeycomb YANG model.

 

 

Hi, Marek

 

Finally I found the issue, at the beginning, bridge-domains is empty, so it is impossible to add a bridge-domain, once bridge-domains is there, you can add a new bridge-domain, it is so for nsh-entry and nsh-map, but before 16.09 is ok.

 

By the way, vxlangpe interface can be created successfully because interfaces are not empty at the beginning.

 

I can work around this, but I expect you can explain why.

 

 

Would need to see logs to check what exactly you are doing.

Let me describe a bit how hc2vpp interfaces work, perhaps it would help you.

 

So if you edit-config message for candidate store:

<rpc message-id="101"

          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

       <edit-config>

         <target>

           <candidate/>

         </target>

…

 

nothing is send to hc2vpp until you issue commit.

That is how netconf works.

In case of restconf, change is immediately applied after you send correct HTTP request.

 

Both restconf and netconf requests result in hc2vpp config changes.

If you issue the same reuest twice (or corresponding netconf and restconf requests),

then only first request results in calling vpp’s binary api.

Second one will be ignored, since data is already in hc2vpp config.

 

Regards,

Marek

 

 

Yes, it can be created with this commit. But it is very weird I can create it by http://10.240.224.185:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/SFF1/yang-ext:mount/v3po:vpp/bridge-domains/bridge-domain/testBD2 after I create testBD by ssh, what is the magic?

 

 

You need to commit config:

 

<rpc message-id="102"

          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

       <commit/>

     </rpc>]]>]]>

 

 

Regards,

Marek

 

From: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) [mailto:mgradzki@...]
Sent: Monday, February 13, 2017 4:25 PM
To: Jan Srnicek -X (jsrnicek - PANTHEON TECHNOLOGIES at Cisco) <jsrnicek@...>; Yang, Yi Y <yi.y.yang@...>; 'honeycomb-dev@...' <honeycomb-dev@...>; hc2vpp@...
Cc: Srihari Raghavan (srihari) <srihari@...>
Subject: RE: [honeycomb-dev] Anybody knows why I got this error when I was adding a bridgedomain

 

+hc2vpp list

 

 

Forgot to mention

 

For hc2vpp ,it must be bild with https://gerrit.fd.io/r/#/c/5065

 

 

 

Hi ,

 

I’ve been finally able to reproduce your behaviour. From my testing it looks like its related to newer ODL  versions,

that’ve bumped to recently. It would be great if you can verify this.

 

Here is patch that downgrades ODL depencencies  - https://gerrit.fd.io/r/#/c/5064/

 

You will need to build honeycomb and hc2vpp manually

 

For honeycomb

 

git clone http://gerrit.fd.io/r/honeycomb && cd honeycomb

git fetch https://gerrit.fd.io/r/honeycomb refs/changes/64/5064/3 && git checkout FETCH_HEAD

mvn clean install –DskipTests

 

For hc2vpp

 

Git clone http://gerrit.fd.io/r/hc2vpp && cd hc2vpp

mvn clean install –DskipTests

 

Run

 

Cd hc2vpp/vpp-integration/minimal-distribution/target/vpp-integration-distribution-1.17.04-SNAPSHOT-hc/vpp-integration-distribution-1.17.04-SNAPSHOT$

Sudo ./honeycomb

 

If my testing conclusions were right, this should remove your issue. Bare in mind that this is just experimental change,(know about one error from

Lisp plugin ,that will be shown on start). We will introduce official changes to take care of this issue soon

 

 

 

 

I did workaround in ODL SFC source code, it puts the below into honeycomb node firstly.

 

{

    "bridge-domains": {

        "bridge-domain": [

            {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

    }

}

 

Then I add bridge domain by the below

 

  {

        "bridge-domain": [

            {

                "name": "SFCVPP",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

 

        ]

    }

 

Error log in ODL, this is from honeycomb’s reply, so honeycomb has the same log.

 

       | 302 - org.opendaylight.netconf.sal-netconf-connector - 1.5.0.SNAPSHOT | RemoteDevice{SFF1}: Error reply from remote device, request: <rpc message-id="m-3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<commit/>

</rpc>

, response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-3">

<rpc-error>

<error-type>application</error-type>

<error-tag>operation-failed</error-tag>

<error-severity>error</error-severity>

<error-message>Unexpected error</error-message>

<error-info>

<error>java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}], modificationType=WRITE, childModification={}]}]</error>

</error-info>

</rpc-error>

</rpc-reply>

 

NetconfDocumentedException{message=Unexpected error, errorType=APPLICATION, errorTag=OPERATION_FAILED, errorSeverity=ERROR, errorInfo={error=java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}], modificationType=WRITE, childModification={}]}]}}

        at org.opendaylight.netconf.api.NetconfDocumentedException.fromXMLDocument(NetconfDocumentedException.java:46)

        at org.opendaylight.netconf.sal.connect.netconf.util.NetconfMessageTransformUtil.checkSuccessReply(NetconfMessageTransformUtil.java:206)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.processMessage(NetconfDeviceCommunicator.java:314)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:262)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:49)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:64)[296:org.opendaylight.netconf.netty-util:1.2.0.SNAPSHOT]

        at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:35)[296:org.opendaylight.netconf.netty-util:1.2.0.SNAPSHOT]

        at org.opendaylight.protocol.framework.AbstractProtocolSession.channelRead0(AbstractProtocolSession.java:53)[285:org.opendaylight.controller.protocol-framework:0.9.0.SNAPSHOT]

        at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)[141:io.netty.codec:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)[141:io.netty.codec:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)[141:io.netty.codec:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)[141:io.netty.codec:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1280)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:890)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:564)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:505)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:419)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:391)[140:io.netty.transport:4.0.37.Final]

        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[139:io.netty.common:4.0.37.Final]

        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)[139:io.netty.common:4.0.37.Final]

        at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]

2017-01-23 17:29:38,687 | WARN  | oupCloseable-3-2 | NetconfRpcFutureCallback

 

 

Please describe me exactly requests for the workaround.

Also please attach honeycomb logs for both cases (failure without workaround, success with workaround).

 

Thanks,

Marek

 

 

Direct invoke is ok, but it is not ok by ODL. The same ODL can work in honeycomb 16.09. in honeycomb 17.01, I can work around this issue by putting bridgedomains with one dummy entry first in ODL.

 

 

Request looks fine, please try to invoke that directly (without ODL – don’t know exactly what your ODL app is doing).

 

Thanks,

Marek

 

 

PUT http://10.240.224.185:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/CLASSIFIER1/yang-ext:mount/v3po:vpp/bridge-domains/bridge-domain/testBD2

 

{

    "bridge-domain": [

        {

            "name": "testBD2",

            "flood": "true",

            "forward": "false",

            "learn": "false",

            "unknown-unicast-flood": "false",

            "arp-termination": "false"

        }

    ]

}

 

The result is

 

{

    "errors": {

        "error": [

            {

                "error-type": "application",

                "error-tag": "operation-failed",

                "error-message": "Problem while PUT operations"

            }

        ]

    }

}

 

 

Sorry, still don’t quite understand, especially the part

“one bridge-domain in list bridge-domains, at the beginning, list bridge-domains doesn’t exist in config data store”

 

Just checked that creating and adding BDs to existing ones work for me. So please explain what requests (url + content) you are

sending step by step (including get to show what is your initial configuration).

 

Regards,

Marek

 

 

 

Marek, one bridge-domain in list bridge-domains, at the beginning, list bridge-domains doesn’t exist in config data store, so you will fail to add a bridge-domain to bridge-domains. This is the issue.

 

{

    "bridge-domains": {

        "bridge-domain": [

            {

                "name": "SFCVPP",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            },

            {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

    }

}

 

 

Please describe one more time what you are trying to do.

You want to add  one bd, then another?

 

Regards,

Marek

 

 

It can’t succeed for ever if no bridgedomains is there.

 

 

Hi,

 

Not sure if I understand your issue. If you target your request at bridge domains node, then you affect all bridge domains,

If you want to add more, then either put then all in the new request or target bridge-domain node:

 

PUT http://localhost:8183/restconf/config/v3po:vpp/bridge-domains/bridge-domain/SFCDUMMY

{

        "bridge-domain": [

              {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

}

 

Regards,

Marek

 

 

Hi, Marek

 

I’m not sure if you received this email, so I resend it.

 

I think this is really a honeycomb issue, at the beginning, in honeycomb config data store, we can’t get bridgedomains because it doesn’t exist, but honeycomb will report error because bridgedomains don’t exist when I add a bridge domain, I can successfully create an empty bridgedomains

 

{

    "bridge-domains": {

  }

}

 

but I can’t get bridgedomains after that because honeycomb think empty means it shouldn’t exist, the behavior in previous honeycomb version isn’t so.

 

In current version, how can I add a bridgedomain successfully? I need to create bridgedomains including one entry, it looks like this

 

{

    "bridge-domains": {

        "bridge-domain": [

              {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

    }

}

 

Then I can add a new bridgedomain, bridgedomains will disappear when I removed all the bridgedomain entry.

 

So I only can create bridgedomains including a dummy bridgedomain entry beforehand in order that a new add operation can work, this is really unreasonable, I hope you can have a fix patch to correct this misbehavior.

 

The issue is same for nsh entries and nsh maps, I think this should be a common issue for all the list nodes in honeycomb YANG model.

 

 

Hi, Marek

 

Finally I found the issue, at the beginning, bridge-domains is empty, so it is impossible to add a bridge-domain, once bridge-domains is there, you can add a new bridge-domain, it is so for nsh-entry and nsh-map, but before 16.09 is ok.

 

By the way, vxlangpe interface can be created successfully because interfaces are not empty at the beginning.

 

I can work around this, but I expect you can explain why.

 

 

Would need to see logs to check what exactly you are doing.

Let me describe a bit how hc2vpp interfaces work, perhaps it would help you.

 

So if you edit-config message for candidate store:

<rpc message-id="101"

          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

       <edit-config>

         <target>

           <candidate/>

         </target>

…

 

nothing is send to hc2vpp until you issue commit.

That is how netconf works.

In case of restconf, change is immediately applied after you send correct HTTP request.

 

Both restconf and netconf requests result in hc2vpp config changes.

If you issue the same reuest twice (or corresponding netconf and restconf requests),

then only first request results in calling vpp’s binary api.

Second one will be ignored, since data is already in hc2vpp config.

 

Regards,

Marek

 

 

Yes, it can be created with this commit. But it is very weird I can create it by http://10.240.224.185:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/SFF1/yang-ext:mount/v3po:vpp/bridge-domains/bridge-domain/testBD2 after I create testBD by ssh, what is the magic?

 

 

You need to commit config:

 

<rpc message-id="102"

          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

       <commit/>

     </rpc>]]>]]>

 

 

Regards,

Marek

 

From: Yang, Yi Y [mailto:yi.y.yang@...]
Sent: 14 lutego 2017 06:42
To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgradzki@...>; Jan Srnicek -X (jsrnicek - PANTHEON TECHNOLOGIES at Cisco) <jsrnicek@...>; 'honeycomb-dev@...' <honeycomb-dev@...>; hc2vpp@...
Cc: Srihari Raghavan (srihari) <srihari@...>
Subject: RE: [honeycomb-dev] Anybody knows why I got this error when I was adding a bridgedomain

 

Thank you so much, but I think Opendaylight is also reverted to Beryllium-SR4 to build, this will be a big effort, I’d like to wait for a final solution for this, now I can work it around.

 

 

+hc2vpp list

 

 

Forgot to mention

 

For hc2vpp ,it must be bild with https://gerrit.fd.io/r/#/c/5065

 

 

 

Hi ,

 

I’ve been finally able to reproduce your behaviour. From my testing it looks like its related to newer ODL  versions,

that’ve bumped to recently. It would be great if you can verify this.

 

Here is patch that downgrades ODL depencencies  - https://gerrit.fd.io/r/#/c/5064/

 

You will need to build honeycomb and hc2vpp manually

 

For honeycomb

 

git clone http://gerrit.fd.io/r/honeycomb && cd honeycomb

git fetch https://gerrit.fd.io/r/honeycomb refs/changes/64/5064/3 && git checkout FETCH_HEAD

mvn clean install –DskipTests

 

For hc2vpp

 

Git clone http://gerrit.fd.io/r/hc2vpp && cd hc2vpp

mvn clean install –DskipTests

 

Run

 

Cd hc2vpp/vpp-integration/minimal-distribution/target/vpp-integration-distribution-1.17.04-SNAPSHOT-hc/vpp-integration-distribution-1.17.04-SNAPSHOT$

Sudo ./honeycomb

 

If my testing conclusions were right, this should remove your issue. Bare in mind that this is just experimental change,(know about one error from

Lisp plugin ,that will be shown on start). We will introduce official changes to take care of this issue soon

 

 

 

 

I did workaround in ODL SFC source code, it puts the below into honeycomb node firstly.

 

{

    "bridge-domains": {

        "bridge-domain": [

            {

                "name": "SFCDUMMY",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

        ]

    }

}

 

Then I add bridge domain by the below

 

  {

        "bridge-domain": [

            {

                "name": "SFCVPP",

                "forward": true,

                "learn": true,

                "unknown-unicast-flood": true,

                "arp-termination": false,

                "flood": true

            }

 

        ]

    }

 

Error log in ODL, this is from honeycomb’s reply, so honeycomb has the same log.

 

       | 302 - org.opendaylight.netconf.sal-netconf-connector - 1.5.0.SNAPSHOT | RemoteDevice{SFF1}: Error reply from remote device, request: <rpc message-id="m-3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<commit/>

</rpc>

, response: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-3">

<rpc-error>

<error-type>application</error-type>

<error-tag>operation-failed</error-tag>

<error-severity>error</error-severity>

<error-message>Unexpected error</error-message>

<error-info>

<error>java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}], modificationType=WRITE, childModification={}]}]</error>

</error-info>

</rpc-error>

</rpc-reply>

 

NetconfDocumentedException{message=Unexpected error, errorType=APPLICATION, errorTag=OPERATION_FAILED, errorSeverity=ERROR, errorInfo={error=java.lang.IllegalArgumentException: Metadata not available for modification NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain, modificationType=TOUCH, childModification={(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}]=NodeModification [identifier=(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)bridge-domain[{(urn:opendaylight:params:xml:ns:yang:v3po?revision=2016-12-14)name=SFCVPP}], modificationType=WRITE, childModification={}]}]}}

        at org.opendaylight.netconf.api.NetconfDocumentedException.fromXMLDocument(NetconfDocumentedException.java:46)

        at org.opendaylight.netconf.sal.connect.netconf.util.NetconfMessageTransformUtil.checkSuccessReply(NetconfMessageTransformUtil.java:206)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.processMessage(NetconfDeviceCommunicator.java:314)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:262)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onMessage(NetconfDeviceCommunicator.java:49)[302:org.opendaylight.netconf.sal-netconf-connector:1.5.0.SNAPSHOT]

        at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:64)[296:org.opendaylight.netconf.netty-util:1.2.0.SNAPSHOT]

        at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handleMessage(AbstractNetconfSession.java:35)[296:org.opendaylight.netconf.netty-util:1.2.0.SNAPSHOT]

        at org.opendaylight.protocol.framework.AbstractProtocolSession.channelRead0(AbstractProtocolSession.java:53)[285:org.opendaylight.controller.protocol-framework:0.9.0.SNAPSHOT]

        at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)[141:io.netty.codec:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)[141:io.netty.codec:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)[141:io.netty.codec:4.0.37.Final]

        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)[141:io.netty.codec:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:321)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1280)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:328)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:890)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:564)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:505)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:419)[140:io.netty.transport:4.0.37.Final]

        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:391)[140:io.netty.transport:4.0.37.Final]

        at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[139:io.netty.common:4.0.37.Final]

        at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145)[139:io.netty.common:4.0.37.Final]

        at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]

2017-01-23 17:29:38,687 | WARN  | oupCloseable-3-2 | NetconfRpcFutureCallback