Re: [openflowplugin-dev] OpenFlow committer nomination : Gobinath Suganthan

[D Arunprakash]

+1

On 2 May 2019 08:32, Shuva Kar  wrote:
+1

On Thu, 2 May 2019, 08:12 Anil Vishnoi, 
mailto:vishnoia...@gmail.com>> wrote:
+1

On Wed, May 1, 2019 at 6:00 PM Anil Vishnoi 
mailto:vishnoia...@gmail.com>> wrote:
Hi OpenFlow plugin committers,

I would like to propose Gobinath Suganthan as a committer to the OpenFlow 
plugin project. Gobinath has done significant contribution in term of code 
contribution and patch review. You can find his contribution here

Merged Patches :

https://git.opendaylight.org/gerrit/#/q/owner:%22Gobinath+Suganthan+%253Cgobinath%2540ericsson.com%253E%22++project:openflowplugin+status:merged

Please respond to this mail thread with your vote +1,0,-1. Also please do not 
drop the openflowplugin-dev mailing list in your response.


--
Thanks
Anil


--
Thanks
Anil
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [release] Autorelease sodium-mvn35-openjdk11 failed to build openflowplugin-extension-api from openflowplugin

[D Arunprakash]

Thanks Robert. We will check it tomorrow.

Regards,
Arun

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org 
 On Behalf Of Robert Varga
Sent: Thursday, April 25, 2019 9:04 PM
To: Jenkins ; 
openflowplugin-dev@lists.opendaylight.org; rele...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [release] Autorelease sodium-mvn35-openjdk11 
failed to build openflowplugin-extension-api from openflowplugin

On 25/04/2019 03:49, Jenkins wrote:
> Attention openflowplugin-devs,
> 
> Autorelease sodium-mvn35-openjdk11 failed to build 
> openflowplugin-extension-api from openflowplugin in build 86. Attached 
> is a snippet of the error message related to the failure that we were able to 
> automatically parse as well as console logs.
> 
> 
> Console Logs:
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease
> -release-sodium-mvn35-openjdk11/86

this boils down to:

> /w/workspace/autorelease-release-sodium-mvn35-openjdk11/openflowplugin/extension/openflowplugin-extension-api/src/main/java/org/opendaylight/openflowplugin/extension/api/GroupingLooseResolver.java:71:
>  error: tag not supported in the generated HTML version: tt
>  * @param data expected to match T extends 
> AugmentableT

i.e. it needs either a fix to comply with HTML5 or an output, as documented in 
https://wiki.opendaylight.org/view/Sodium_platform_upgrade#javadoc-maven-plugin

Regards,
Robert

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Humbly requesting review and merge of 4 changes

[D Arunprakash]

@SOMASHEKHAR MANOHARA 
JAVALAGI<mailto:somashekhar.manohara.javal...@ericsson.com>, openflowplugin 
csit seems to unstable in master, could you please check it?

@Michael Vorburger<mailto:vorbur...@redhat.com>, we are seeing CSIT unstable in 
openflowplugin, let’s try to fix that first before merging further reviews.

Regards,
Arun

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Thursday, January 17, 2019 5:56 AM
To: D Arunprakash ; Gobinath . 
; Anil Vishnoi 
Cc: openflowplugin-dev 
Subject: Humbly requesting review and merge of 4 changes

Esteemed OpenFlowPlugin committers,

May I humbly request ;-) your review and merge of the following 4 changes 
pending since 4/3/1 weeks:

* https://git.opendaylight.org/gerrit/#/c/78859/
* https://git.opendaylight.org/gerrit/#/c/78898/
* https://git.opendaylight.org/gerrit/#/c/78899/
* https://git.opendaylight.org/gerrit/#/c/79452/

Thanking you very much,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com<mailto:vorbur...@redhat.com> | IRC: vorburger @freenode | 
~ = http://vorburger.ch<http://vorburger.ch/>
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [netvirt-dev] problems with openflowplugin/ovs connections

[D Arunprakash]

We will look into this and log a jira and add the relevant links.

Regards,
Arun

-Original Message-
From: Jamo Luhrsen [mailto:jluhr...@gmail.com] 
Sent: Tuesday, November 06, 2018 5:56 AM
To: D Arunprakash ; openflowplugin-dev 
; odl netvirt dev 

Subject: Re: [netvirt-dev] problems with openflowplugin/ovs connections

Hi Arun,

any update on this one? do we need a jira to track it? These logs are coming a 
lot and makes it very cumbersome to look at. Not to mention, they may be 
indicating some problem internally.

JamO

On 10/29/18 4:29 PM, Jamo Luhrsen wrote:
> Hi Arun,
> 
> sorry for the late response. We don't have packet captures on the odl 
> nodes, but we do have them on the ovs nodes (2 computes and 1 control).
> 
> they are done on a per suite basis, but I would just look at the 
> captures during the elan suite since I know for sure that we are 
> seeing all these messages when that suite is running.
> 
> just look here:
> 
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csi
> t-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-snat-conntra
> ck-oxygen/86/control_1/
> 
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csi
> t-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-snat-conntra
> ck-oxygen/86/compute_1/
> 
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csi
> t-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-snat-conntra
> ck-oxygen/86/compute_2/
> 
> 
> in those folders you'll find a file like:
> 
> tcpdump_port_6653__09_elan__10.30.170.134.pcap.xz
> 
> 
> Thanks,
> JamO
> 
> 
> 
> On 10/17/18 10:22 PM, D Arunprakash wrote:
>> Hi Jamo,
>> Do we have packet capture at odl node level, there seems to be connection 
>> established on 6653 port in a repeated manner.
>>
>> Regards,
>> Arun
>>
>> -Original Message-
>> From: netvirt-dev-boun...@lists.opendaylight.org 
>> [mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Jamo 
>> Luhrsen
>> Sent: Wednesday, October 17, 2018 11:06 PM
>> To: openflowplugin-dev ; 
>> odl netvirt dev 
>> Subject: [netvirt-dev] problems with openflowplugin/ovs connections
>>
>> Hi OFP,
>>
>> we are debugging different failures in netvirt CSIT and it's starting 
>> to feel like we have some problems coming from OFP. To start, could someone 
>> take a look at this one:
>>
>> https://jira.opendaylight.org/projects/OPNFLWPLUG/issues/OPNFLWPLUG-1
>> 039?filter=allopenissues
>>
>> I think this might only be happening in our clustering jobs, but it 
>> seems like the high level problem is that we can't set the connected node to 
>> SLAVE and cancel the ovs connect (after 20s). Then it just repeats.
>>
>>
>> Also, we see a ton of logs like the below. what is this 127.0.0.1 
>> nodeid:null thing? Since this is in the karaf.log, it seems that 127.0.0.1 
>> would be on the host running ODL and that's not a node that we are running 
>> ovs (that I know of):
>>
>>
>> 2018-10-07T21:54:38,904 | INFO  | epollEventLoopGroup-11-7 | 
>> AbstractConnectionAdapter    | 391 - 
>> org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 
>> 0.6.4 | The channel outbound queue size:1024
>> 2018-10-07T21:54:38,904 | INFO  | epollEventLoopGroup-9-6 | 
>> SystemNotificationsListenerImpl  | 382 - 
>> org.opendaylight.openflowplugin.impl - 0.6.4 | ConnectionEvent: 
>> Connection closed by device, Device:/127.0.0.1:52538, NodeId:null
>> 2018-10-07T21:54:38,905 | INFO  | epollEventLoopGroup-11-7 | 
>> SystemNotificationsListenerImpl  | 382 - 
>> org.opendaylight.openflowplugin.impl - 0.6.4 | ConnectionEvent: 
>> Connection closed by device, Device:/127.0.0.1:49130, NodeId:null
>> 2018-10-07T21:54:38,906 | INFO  | epollEventLoopGroup-11-6 | 
>> SystemNotificationsListenerImpl  | 382 - 
>> org.opendaylight.openflowplugin.impl - 0.6.4 | ConnectionEvent: 
>> Connection closed by device, Device:/127.0.0.1:49126, NodeId:null
>> 2018-10-07T21:54:38,906 | INFO  | epollEventLoopGroup-9-8 | 
>> SystemNotificationsListenerImpl  | 382 - 
>> org.opendaylight.openflowplugin.impl - 0.6.4 | ConnectionEvent: 
>> Connection closed by device, Device:/127.0.0.1:52546, NodeId:null
>> 2018-10-07T21:54:38,906 | INFO  | epollEventLoopGroup-9-7 | 
>> SystemNotificationsListenerImpl  | 382 - 
>> org.opendaylight.openflowplugin.impl - 0.6.4 | ConnectionEvent: 
>> Connection closed by device, Device:/127.0.0.1:52542, NodeId:null
>> 2018-10-07T21:54:40,912 | INFO  | epollEventLoopGroup-9-9 | 
>> AbstractConnectionAdapter

Re: [openflowplugin-dev] [netvirt-dev] problems with openflowplugin/ovs connections

[D Arunprakash]

Hi Jamo,
Do we have packet capture at odl node level, there seems to be connection 
established on 6653 port in a repeated manner.

Regards,
Arun

-Original Message-
From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Jamo Luhrsen
Sent: Wednesday, October 17, 2018 11:06 PM
To: openflowplugin-dev ; odl netvirt 
dev 
Subject: [netvirt-dev] problems with openflowplugin/ovs connections

Hi OFP,

we are debugging different failures in netvirt CSIT and it's starting to feel 
like we have some problems coming from OFP. To start, could someone take a look 
at this one:

https://jira.opendaylight.org/projects/OPNFLWPLUG/issues/OPNFLWPLUG-1039?filter=allopenissues

I think this might only be happening in our clustering jobs, but it seems like 
the high level problem is that we can't set the connected node to SLAVE and 
cancel the ovs connect (after 20s). Then it just repeats.


Also, we see a ton of logs like the below. what is this 127.0.0.1 nodeid:null 
thing? Since this is in the karaf.log, it seems that 127.0.0.1 would be on the 
host running ODL and that's not a node that we are running ovs (that I know of):


2018-10-07T21:54:38,904 | INFO  | epollEventLoopGroup-11-7 | 
AbstractConnectionAdapter| 391 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.6.4 | 
The channel outbound queue size:1024
2018-10-07T21:54:38,904 | INFO  | epollEventLoopGroup-9-6 | 
SystemNotificationsListenerImpl  | 382 - org.opendaylight.openflowplugin.impl - 
0.6.4 | ConnectionEvent: Connection closed by device, Device:/127.0.0.1:52538, 
NodeId:null
2018-10-07T21:54:38,905 | INFO  | epollEventLoopGroup-11-7 | 
SystemNotificationsListenerImpl  | 382 - org.opendaylight.openflowplugin.impl - 
0.6.4 | ConnectionEvent: Connection closed by device, Device:/127.0.0.1:49130, 
NodeId:null
2018-10-07T21:54:38,906 | INFO  | epollEventLoopGroup-11-6 | 
SystemNotificationsListenerImpl  | 382 - org.opendaylight.openflowplugin.impl - 
0.6.4 | ConnectionEvent: Connection closed by device, Device:/127.0.0.1:49126, 
NodeId:null
2018-10-07T21:54:38,906 | INFO  | epollEventLoopGroup-9-8 | 
SystemNotificationsListenerImpl  | 382 - org.opendaylight.openflowplugin.impl - 
0.6.4 | ConnectionEvent: Connection closed by device, Device:/127.0.0.1:52546, 
NodeId:null
2018-10-07T21:54:38,906 | INFO  | epollEventLoopGroup-9-7 | 
SystemNotificationsListenerImpl  | 382 - org.opendaylight.openflowplugin.impl - 
0.6.4 | ConnectionEvent: Connection closed by device, Device:/127.0.0.1:52542, 
NodeId:null
2018-10-07T21:54:40,912 | INFO  | epollEventLoopGroup-9-9 | 
AbstractConnectionAdapter| 391 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.6.4 | 
The channel outbound queue size:1024
2018-10-07T21:54:40,913 | INFO  | epollEventLoopGroup-9-10 | 
AbstractConnectionAdapter| 391 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.6.4 | 
The channel outbound queue size:1024
2018-10-07T21:54:40,913 | INFO  | epollEventLoopGroup-11-8 | 
AbstractConnectionAdapter| 391 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.6.4 | 
The channel outbound queue size:1024
2018-10-07T21:54:40,914 | INFO  | epollEventLoopGroup-9-11 | 
AbstractConnectionAdapter| 391 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.6.4 | 
The channel outbound queue size:1024
2018-10-07T21:54:40,915 | INFO  | epollEventLoopGroup-11-9 | 
AbstractConnectionAdapter| 391 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.6.4 | 
The channel outbound queue size:1024
2018-10-07T21:54:40,915 | INFO  | epollEventLoopGroup-11-10 | 
AbstractConnectionAdapter| 391 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 0.6.4 | 
The channel outbound queue size:1024



Thanks,
JamO
___
netvirt-dev mailing list
netvirt-...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/netvirt-dev
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] SBI is for getting called for multipart requests

[D Arunprakash]

Hi Rajesh,
Could you please let us know what multipart request you are trying to send to 
openflow switch?

There is no direct rpc/config model listener exposed at openflowplugin level to 
send multipart-request.

Openflowjava exposes rpc to send multipart "POST 
/operations/openflow-protocol:multipart-request", if you let us know exactly 
what you are trying to send and we can help you more.

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Rajesh 
Kumar
Sent: Tuesday, August 28, 2018 2:16 PM
To: openflowplugin-dev@lists.opendaylight.org
Subject: [openflowplugin-dev] SBI is for getting called for multipart requests


Hi,



when I am sending a multipart request using NBI " PUT 
http://127.0.0.1:8181/restconf/config/opendaylight-multipart-types:multipart-request;
 simply getting HTTP 200 response. this call is not making SBI call to update 
the device. please let me know if this implementation is not present in Oxigen 
release or this is correct behavior for multipart requests.



I also didn't found implementation class for OpenflowProtocolService in 
openflowplugin source code. is this interface implementation required for 
calling SBI?



Thanks & Regards

Rajesh Kumar

L Technology Services Ltd

www.LntTechservices.com

This Email may contain confidential or privileged information for the intended 
recipient (s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Netvirt Cluster CSIT : Table Miss Entry programming failing randomly

[D Arunprakash]

Faseela,
Could you please enable the following package logging and provide the logs?

log:set DEBUG org.opendaylight.openflowplugin.impl

Regards,
Arun

From: Faseela K
Sent: Tuesday, July 24, 2018 11:44 PM
To: Anil Vishnoi 
Cc: D Arunprakash ; Gobinath . 
; Sam Hague ; Dayavanti Gopal Kamath 
; Jamo Luhrsen ; 
Vishal Thapar ; openflowplugin-dev@lists.opendaylight.org
Subject: RE: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

Hi Arun,
We are still hitting this issue, and this can be seen on stable/oxygen as 
well.
 In some cases the flow will be programmed initially, but after some time 
it disappears.

 I do see a lot of "Switch Idle state occurred, 
node=/10.30.170.51:60858|auxId=0" messages in the logs. Is that anything to 
worry about?

  If there is any specific TRACE logs to be enabled while running the CSIT, 
could you please let me know? I can run the CSIT with the same and supply the 
logs.
Thanks,
Faseela

From: Faseela K
Sent: Tuesday, July 17, 2018 1:24 PM
To: Anil Vishnoi mailto:vishnoia...@gmail.com>>
Cc: D Arunprakash 
mailto:d.arunprak...@ericsson.com>>; Gobinath . 
mailto:gobin...@ericsson.com>>; Sam Hague 
mailto:sha...@redhat.com>>; Dayavanti Gopal Kamath 
mailto:dayavanti.gopal.kam...@ericsson.com>>;
 Jamo Luhrsen mailto:jluhr...@gmail.com>>; Vishal Thapar 
mailto:vtha...@redhat.com>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Netvirt Cluster CSIT : Table Miss Entry programming failing randomly

Anil,

I have raised the below JIRA, where I see Table Miss flow for Table 43 is 
sometimes not getting programmed on one of the computes in netvirt 3 node CSIT.
https://jira.opendaylight.org/browse/OPNFLWPLUG-1028
I do see flow being pushed to config/inventory by netvirt, but it is missing on 
switch.
This makes the basic DHCP itself fail for netvirt as this is one of the 
important flows needed for all broadcasts to work.
Any pointers?

Thanks,
Faseela
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Flow addition failed - missing group

[D Arunprakash]

Hi Vishal,
This improvement will make sure to push the group first and followed by flow 
(only if both the flow and group present the config ☺).

When the application programs both the flow and group at the same instance 
there is a chance that flow can reach the switch before group and now 
dependency will be enforced.

Regards,
Arun
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Vishal 
Thapar
Sent: Tuesday, July 17, 2018 8:50 AM
To: Luis Gomez ; Aswin Suryanarayanan 
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Flow addition failed - missing group

Thanks Luis. I recalled discussions on this wasn't sure if it was already fixed 
or a WiP. Will add this as dependency to the Netvirt bug.


On Mon, Jul 16, 2018 at 11:14 PM, Luis Gomez 
mailto:ece...@gmail.com>> wrote:
This is a known issue of current FRM, see ticket below:

https://jira.opendaylight.org/browse/OPNFLWPLUG-991

AFAIK work is in progress but no merge yet.

BR/Luis



On Jul 16, 2018, at 9:43 AM, Vishal Thapar 
mailto:vtha...@redhat.com>> wrote:

Greetings OFP Devs,

We're seeing an issue in Netvirt CSIT. The failure has been root caused to a 
missing flow and from OVS logs [1] we can see the reason being flow is added 
before the group.


2018-07-15T03:42:58.872Z|09648|vconn|DBG|tcp:10.30.170.132:6653:
 received: OFPT_FLOW_MOD (OF1.3) (xid=0x1142): ADD table:26 
priority=5,ip,metadata=0x30d78/0xfe cookie:0x806 
actions=set_field:0x186bc->tun_id,group:225006

2018-07-15T03:42:58.872Z|09649|connmgr|INFO|br-int<->tcp:10.30.170.132:6653:
 sending OFPBAC_BAD_OUT_GROUP error reply to OFPT_FLOW_MOD message

2018-07-15T03:42:58.872Z|09650|vconn|DBG|tcp:10.30.170.132:6653:
 sent (Success): OFPT_ERROR (OF1.3) (xid=0x1142): OFPBAC_BAD_OUT_GROUP

OFPT_FLOW_MOD (OF1.3) (xid=0x1142):

(***truncated to 64 bytes from 112***)

  04 0e 00 70 00 00 11 42-00 00 00 00 08 00 00 06 |...p...B|

0010  00 00 00 00 00 00 00 00-1a 00 00 00 00 00 00 05 ||

0020  ff ff ff ff ff ff ff ff-ff ff ff ff 00 00 00 00 ||

0030  00 01 00 1e 80 00 05 10-00 00 00 00 00 03 0d 78 |...x|

2018-07-15T03:42:58.872Z|09651|vconn|DBG|tcp:10.30.170.132:6653:
 received: OFPT_GROUP_MOD (OF1.3) (xid=0x1143):

 ADD 
group_id=225006,type=all,bucket=actions=load:0x300->NXM_NX_REG6[],resubmit(,220)


Wasn't there some feature/fix done in OFP to ensure groups were always added 
before a flow? Or was that only for resync use case? Am I misremembering a 
feature that was never implemented or is this a bug?

Regards,
Vishal.

[1] 
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-upstream-stateful-snat-conntrack-oxygen/329/compute_2/ovs-vswitchd.log.gz

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev


___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [netvirt-dev] ovs 2.8.2 does not work well in csit

[D Arunprakash]

Aswin,
Could you please refer the attached packet-in dump, where there are new ct 
fields (120, 121, 124, 125) in the match?

So, if we use ct_clear in the flow, is it expected to clear the new ct fields 
as well. I’m not much familiar with CT fields, could you please check and let 
me know what we should do now?

Is the ct_clear bug present in ovs2.8 as well?


Regards,
Arun
From: Aswin Suryanarayanan [mailto:asury...@redhat.com]
Sent: Wednesday, July 11, 2018 11:24 AM
To: D Arunprakash 
Cc: Anil Vishnoi ; Jamo Luhrsen ; 
openflowplugin-dev ; Luis Gomez 
; odl netvirt dev 
Subject: Re: [netvirt-dev] ovs 2.8.2 does not work well in csit



On Wed, Jul 11, 2018 at 10:17 AM, D Arunprakash 
mailto:d.arunprak...@ericsson.com>> wrote:
Aswin,

From http://www.openvswitch.org/support/dist-docs/ovs-ofctl.8.html, ct_clear 
clears the following ct fields,

ct_clear
 Clears connection tracking state from the  flow,  zeroing
 ct_state, ct_zone, ct_mark, and ct_label.

 This action was introduced in Open vSwitch 2.6.90.

But from the ovs2.8+, there are new CT fields introduced, will ct_clear those 
as well?

The ct_clear is intended to clear the states, I don't think (I could be wrong) 
the other fields will be present in a packet submitted back from to the 
pipeline from conntrack, they are used when we send the packet to conntrack.
In this case I think we need to identify who added these extra fields, if it 
was due to acl service it should have been cleared by ct_clear. But the 
ct_clear functionality was broken in the kernel datapath in the initial ovs2.9 
release and was addressed by [*]. We should have this fix for this to work as 
expected.

[*]https://patchwork.ozlabs.org/patch/864353/

CONNECTION TRACKING FIELDS
   Summary:
   Name  Bytes   Mask   RW?   Prereqs   NXM/OXM Support
     ──  ─      
   ct_state  4   yesnonone  OVS 2.5+
   ct_zone   2   no nonone  OVS 2.5+
   ct_mark   4   yesyes   none  OVS 2.5+
   ct_label  16  yesyes   none  OVS 2.5+
   ct_nw_src 4   yesnoCTOVS 2.8+
   ct_nw_dst 4   yesnoCTOVS 2.8+

   ct_ipv6_src   16  yesnoCTOVS 2.8+
   ct_ipv6_dst   16  yesnoCTOVS 2.8+
   ct_nw_proto   1   no noCTOVS 2.8+
   ct_tp_src 2   yesnoCTOVS 2.8+
   ct_tp_dst 2   yesnoCTOVS 2.8+


Regards,
Arun

From: 
netvirt-dev-boun...@lists.opendaylight.org<mailto:netvirt-dev-boun...@lists.opendaylight.org>
 
[mailto:netvirt-dev-boun...@lists.opendaylight.org<mailto:netvirt-dev-boun...@lists.opendaylight.org>]
 On Behalf Of Aswin Suryanarayanan
Sent: Tuesday, July 10, 2018 11:06 PM
To: Anil Vishnoi mailto:vishnoia...@gmail.com>>
Cc: Jamo Luhrsen mailto:jluhr...@redhat.com>>; 
openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Luis Gomez mailto:ece...@gmail.com>>; odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>

Subject: Re: [netvirt-dev] ovs 2.8.2 does not work well in csit



On Mon, Jul 9, 2018 at 11:25 PM, Anil Vishnoi 
mailto:vishnoia...@gmail.com>> wrote:
Sam,

We are currently working on getting all the NSH related patches from jamie in, 
once we get those patches in, we can see if we see these other serialization 
issue.

On Mon, Jul 9, 2018 at 8:24 AM Sam Hague 
mailto:sha...@redhat.com>> wrote:
Arun, Anil,

thanks for merging [1]. There are other deserialization problems failing the 
tests. I filed [3] to track the issues. Can you take a look and see if more 
similar changes are needed? The conntrack fields overlapping with the nsh 
fields definitely makes sense as the tests are conntrack based.

Arun, Jaime,

did you also try with ovs 2.9.x? I am guessing the same problems are there.

Thanks, Sam

[1] https://git.opendaylight.org/gerrit/#/c/73735/
[2] https://git.opendaylight.org/gerrit/#/c/72320/.
[3] https://jira.opendaylight.org/browse/OPNFLWPLUG-1023
[4] 
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/196/shague-queens-netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/7/odl_1/odl1_karaf.log.gz

On Mon, Jul 9, 2018 at 4:09 AM Jaime Caamaño Ruiz 
mailto:jcaam...@suse.de>> wrote:
Hello Sam

This is most likely happenning because since OVS 2.8, openflow OXM/NXM
ids that were unofficially used for the NSH fields on Yi Yang patch are
now being officially used for other different fields.

On this specific case, it is OXM field 120 in the Nicira NXM1 class,
which Yi Yang used for NshNp, but is now officially used for ct_nw_src.
So openflowplugin is wrongly interpreting ct_nw_src as NshNp.

BR
Jaime.



-Original Message-
From: Sam Hague mailto:sha...@redhat.c

Re: [openflowplugin-dev] [netvirt-dev] ovs 2.8.2 does not work well in csit

[D Arunprakash]

Aswin,

From http://www.openvswitch.org/support/dist-docs/ovs-ofctl.8.html, ct_clear 
clears the following ct fields,

ct_clear
 Clears connection tracking state from the  flow,  zeroing
 ct_state, ct_zone, ct_mark, and ct_label.

 This action was introduced in Open vSwitch 2.6.90.

But from the ovs2.8+, there are new CT fields introduced, will ct_clear those 
as well?

CONNECTION TRACKING FIELDS
   Summary:
   Name  Bytes   Mask   RW?   Prereqs   NXM/OXM Support
     ──  ─      
   ct_state  4   yesnonone  OVS 2.5+
   ct_zone   2   no nonone  OVS 2.5+
   ct_mark   4   yesyes   none  OVS 2.5+
   ct_label  16  yesyes   none  OVS 2.5+
   ct_nw_src 4   yesnoCTOVS 2.8+
   ct_nw_dst 4   yesnoCTOVS 2.8+

   ct_ipv6_src   16  yesnoCTOVS 2.8+
   ct_ipv6_dst   16  yesnoCTOVS 2.8+
   ct_nw_proto   1   no noCTOVS 2.8+
   ct_tp_src 2   yesnoCTOVS 2.8+
   ct_tp_dst 2   yesnoCTOVS 2.8+


Regards,
Arun

From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Aswin 
Suryanarayanan
Sent: Tuesday, July 10, 2018 11:06 PM
To: Anil Vishnoi 
Cc: Jamo Luhrsen ; openflowplugin-dev 
; Luis Gomez ; odl 
netvirt dev 
Subject: Re: [netvirt-dev] ovs 2.8.2 does not work well in csit



On Mon, Jul 9, 2018 at 11:25 PM, Anil Vishnoi 
mailto:vishnoia...@gmail.com>> wrote:
Sam,

We are currently working on getting all the NSH related patches from jamie in, 
once we get those patches in, we can see if we see these other serialization 
issue.

On Mon, Jul 9, 2018 at 8:24 AM Sam Hague 
mailto:sha...@redhat.com>> wrote:
Arun, Anil,

thanks for merging [1]. There are other deserialization problems failing the 
tests. I filed [3] to track the issues. Can you take a look and see if more 
similar changes are needed? The conntrack fields overlapping with the nsh 
fields definitely makes sense as the tests are conntrack based.

Arun, Jaime,

did you also try with ovs 2.9.x? I am guessing the same problems are there.

Thanks, Sam

[1] https://git.opendaylight.org/gerrit/#/c/73735/
[2] https://git.opendaylight.org/gerrit/#/c/72320/.
[3] https://jira.opendaylight.org/browse/OPNFLWPLUG-1023
[4] 
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/196/shague-queens-netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/7/odl_1/odl1_karaf.log.gz

On Mon, Jul 9, 2018 at 4:09 AM Jaime Caamaño Ruiz 
mailto:jcaam...@suse.de>> wrote:
Hello Sam

This is most likely happenning because since OVS 2.8, openflow OXM/NXM
ids that were unofficially used for the NSH fields on Yi Yang patch are
now being officially used for other different fields.

On this specific case, it is OXM field 120 in the Nicira NXM1 class,
which Yi Yang used for NshNp, but is now officially used for ct_nw_src.
So openflowplugin is wrongly interpreting ct_nw_src as NshNp.

BR
Jaime.



-Original Message-
From: Sam Hague mailto:sha...@redhat.com>>
To: Anil Vishnoi mailto:vishnoia...@gmail.com>>
Cc: Dayavanti Gopal Kamath 
mailto:dayavanti.gopal.kam...@ericsson.com>>,
 Luis
Gomez mailto:ece...@gmail.com>>, HCL Tech Venkatrangan G - 
ERS http://hcl.com>>, odl netvirt dev 
mailto:netvirt-...@lists.opendaylight.org>>,
openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>,
 Jamo
Luhrsen mailto:jluhr...@redhat.com>>, Manuel Buil 
mailto:mb...@suse.com>>, jcaamano@s
use.de
Subject: Re: [netvirt-dev] ovs 2.8.2 does not work well in csit
Date: Sun, 8 Jul 2018 22:44:30 -0400



On Sun, Jul 8, 2018 at 5:05 PM Anil Vishnoi 
mailto:vishnoia...@gmail.com>>
wrote:
> I believe upstream openflowplugin CSIT uses 2.8.0/1 version and that
> did not contain the new NSH support and that's working fine. Seems
> like the new NSH support is causing this issue. Looking like in your
> CSIT someone is trying to install the flow with the NSH match or your
> switch has NSH based flow. MatchConvertor comes into play when either
> you are pushing flow down to the switch or reading and deserializing
> the stats/packet_in coming from switch.
>
>

Anil, the exception is coming from packet_in messages and not a flow
being installed. The features for sfc/nsh are not installed so pretty
sure nothing is trying to use nsh. Can you look again at the two
exceptions to see if that is correct? OVS 2.8.0 added userspace NSH
support, with more support added in 2.8.1 and 2.8.2. I see the ofp csit
is using 2.8.1. it has deserialization errors but not the same as the
netvirt csit. ovs 2.8.2 says it moved the NSH support to the standard
spec support so maybe that is why it is causing more problems that
2.8.1?

There 

Re: [openflowplugin-dev] [netvirt-dev] ovs 2.8.2 does not work well in csit

[D Arunprakash]

Sam,
I have seen this issue as well in downstream, while debugging it we have found 
out the codec registered for NshNp fields were wrong in the code.

Raised a review [1] for the same, but later found out it was already fixed by 
Jaime’s review [2] as part of new NSH implementation.
Let us know if it’s needed urgently, so we can merge the path [1].

[1] https://git.opendaylight.org/gerrit/#/c/73735/
[2] https://git.opendaylight.org/gerrit/#/c/72320/.

Regards,
Arun

From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Sam Hague
Sent: Monday, July 09, 2018 8:15 AM
To: Anil Vishnoi 
Cc: odl netvirt dev ; Luis Gomez 
; openflowplugin-dev 
; Jamo Luhrsen 
Subject: Re: [netvirt-dev] ovs 2.8.2 does not work well in csit


On Sun, Jul 8, 2018 at 5:05 PM Anil Vishnoi 
mailto:vishnoia...@gmail.com>> wrote:
I believe upstream openflowplugin CSIT uses 2.8.0/1 version and that did not 
contain the new NSH support and that's working fine. Seems like the new NSH 
support is causing this issue. Looking like in your CSIT someone is trying to 
install the flow with the NSH match or your switch has NSH based flow. 
MatchConvertor comes into play when either you are pushing flow down to the 
switch or reading and deserializing the stats/packet_in coming from switch.

Anil, the exception is coming from packet_in messages and not a flow being 
installed. The features for sfc/nsh are not installed so pretty sure nothing is 
trying to use nsh. Can you look again at the two exceptions to see if that is 
correct? OVS 2.8.0 added userspace NSH support, with more support added in 
2.8.1 and 2.8.2. I see the ofp csit is using 2.8.1. it has deserialization 
errors but not the same as the netvirt csit. ovs 2.8.2 says it moved the NSH 
support to the standard spec support so maybe that is why it is causing more 
problems that 2.8.1?
We already have patches pushed by Jamie to implement these new NSH fields and 
remove the old one, hopefully that should fix it.
How far along are these patches?

On Sun, Jul 8, 2018 at 5:26 AM Sam Hague 
mailto:sha...@redhat.com>> wrote:
Adding Daya to see if they have been doing any testing with ovs 2.8.2 or later. 
Also forgot netvirt-dev and openflowplugin-dev lists.

On Sat, Jul 7, 2018 at 5:05 PM Sam Hague 
mailto:sha...@redhat.com>> wrote:
Jamo,

did we ever have any runs using ovs 2.8.2 - or really anything later than 
2.7.2? [1] is a job using ovs 2.8.2 and it fails a few tests because of an 
openflow deserialization error with some NSH packets - but this is just our 
normal csit and not anything related to sfc. My 2.9 jobs also had some failures 
but I didn't inspect them before the sandbox cleared up this weekend.

NSH support was added in 2.8 so that makes sense this could cause a problem. 
The exception below is coming out when the test fails - a ping fails, so I 
guess an arp or other punt packet is being mapped to nsh and not being decoded 
by openflowplugin.

Jaime, Venkat,

have you seen issues like this? Is it because openflowplugin has not been 
updated to use the new nsh and maybe some older nsh support is causing problems?

Thanks, Sam

[1] 
https://jenkins.opendaylight.org/sandbox/job/shague-queens-netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/3/


2018-07-07T15:28:56,461 | WARN  | epollEventLoopGroup-9-1 | 
MatchExtensionHelper | 364 - org.opendaylight.openflowplugin - 
0.7.0.SNAPSHOT | Convertor for 
MatchEntry{_matchEntryValue=NshNpCaseValue{_nshNpValues=NshNpValues{_value=41, 
augmentation=[]}, augmentation=[]}, _oxmClass=interface 
org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.oxm.rev150225.Nxm1Class, 
_oxmMatchField=interface 
org.opendaylight.yang.gen.v1.urn.opendaylight.openflowjava.nx.match.rev140421.NxmNxNshNp,
 _hasMask=false, augmentation=[]} for version 4 with match path 
PACKET_IN_MESSAGE_MATCH not found.

2018-07-07T15:28:56,462 | WARN  | epollEventLoopGroup-9-1 | OFDecoder   
 | 386 - 
org.opendaylight.openflowplugin.openflowjava.openflow-protocol-impl - 
0.7.0.SNAPSHOT | Message deserialization failedjava.lang.NullPointerException: 
null  at 
org.opendaylight.openflowplugin.openflow.md.core.extension.MatchExtensionHelper.injectExtension(MatchExtensionHelper.java:83)
 [364:org.opendaylight.openflowplugin:0.7.0.SNAPSHOT]   at 
org.opendaylight.openflowplugin.impl.protocol.deserialization.match.MatchDeserializer.deserializeEntry(MatchDeserializer.java:104)

___
netvirt-dev mailing list
netvirt-...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/netvirt-dev


--
Thanks
Anil
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] OpenflowPlugin: Invalid length for IPv6 Address in OXM field - Reg

[D Arunprakash]

Hi Vishal,
Even I'm finding ipv4 address has prefix in config inventory. Could you please 
cross check how apps writes into config ds?

Also, when I push the ipv6 flow without prefix, it was failing for me with 
NumberFormatException and not sure how it works for Karthikeyan.

"ipv4-source": "10.10.0.4/32",

Even the model is using ipv6-prefix.

grouping "ipv6-match-fields" {
leaf ipv6-source {
description "IPv6 source address.";
type inet:ipv6-prefix;
}

leaf ipv6-destination {
description "IPv6 destination address.";
type inet:ipv6-prefix;
}
grouping "ipv4-match-fields" {
leaf ipv4-source {
description "IPv4 source address.";
type inet:ipv4-prefix;
}

leaf ipv4-destination {
description "IPv4 destination address.";
type inet:ipv4-prefix;
}

}


Regards,
Arun 
-Original Message-
From: Vishal Thapar [mailto:vtha...@redhat.com] 
Sent: Thursday, May 31, 2018 6:36 AM
To: D Arunprakash 
Cc: Karthikeyan ; Sridhar Alaparthi 
; netvirt-dev 
; 
openflowplugin-dev@lists.opendaylight.org; Naveen Manyam Subramanyam 

Subject: Re: [openflowplugin-dev] OpenflowPlugin: Invalid length for IPv6 
Address in OXM field - Reg

Hi Arun,

Applications don't have to specify prefix length '/32' for IPv4 addresses so 
why do they need to explicitly specify it for IPv6? Just as OFP defaults /32 
for IPv4, can't it use /128 for IPv6 addresses?

Regards,
Vishal.

On Thu, May 31, 2018 at 12:56 AM, D Arunprakash  
wrote:
> Hi Karthikeyan,
>
> Ipv6 address is 128 bits, which means oxm value length should be 16 
> bytes 128.
>
>
>
> Normally ipv6 address will be represented with prefix length. (/128).
>
>
>
> Used your config flow and just added /128 to the ipv6 src address and 
> programmed without any issues.
>
>
>
> "ipv6-source":
> "fe80:0:0:0:f816:3eff:feb4:8492/128"
>
>
>
> Config ds dump:
>
> "flow-node-inventory:table": [
>
> {
>
> "id": 240,
>
> "flow": [
>
> {
>
> "id":
> "Ingress_ICMPv6_392318374877_5_fa:16:3e:b4:84:92_134_LinkLocal_Permit_
> ",
>
> "table_id": 240,
>
> "installHw": true,
>
> "strict": false,
>
> "flow-name": "ACL",
>
> "idle-timeout": 0,
>
> "barrier": false,
>
> "priority": 63010,
>
> "hard-timeout": 0,
>
> "match": {
>
> "ethernet-match": {
>
> "ethernet-type": {
>
> "type": 34525
>
> }
>
> },
>
> "ip-match": {
>
> "ip-protocol": 58
>
> },
>
> "icmpv6-match": {
>
> "icmpv6-code": 0,
>
> "icmpv6-type": 134
>
> },
>
>
> "openflowplugin-extension-general:extension-list": [
>
> {
>
> "extension-key":
> "openflowplugin-extension-nicira-match:nxm-nx-reg6-key",
>
> "extension": {
>
>
> "openflowplugin-extension-nicira-match:nxm-nx-reg": {
>
> "reg":
> "nicira-match:nxm-nx-reg6",
>
> "mask": 268435200,
>
> "value": 1280
>
> }
>
> }
>
> }
>
> ],
>
>   

Re: [openflowplugin-dev] OpenflowPlugin: Invalid length for IPv6 Address in OXM field - Reg

[D Arunprakash]

Hi Karthikeyan,
Ipv6 address is 128 bits, which means oxm value length should be 16 bytes 128.

Normally ipv6 address will be represented with prefix length. (/128).

Used your config flow and just added /128 to the ipv6 src address and 
programmed without any issues.

"ipv6-source": 
"fe80:0:0:0:f816:3eff:feb4:8492/128"

Config ds dump:
"flow-node-inventory:table": [
{
"id": 240,
"flow": [
{
"id": 
"Ingress_ICMPv6_392318374877_5_fa:16:3e:b4:84:92_134_LinkLocal_Permit_",
"table_id": 240,
"installHw": true,
"strict": false,
"flow-name": "ACL",
"idle-timeout": 0,
"barrier": false,
"priority": 63010,
"hard-timeout": 0,
"match": {
"ethernet-match": {
"ethernet-type": {
"type": 34525
}
},
"ip-match": {
"ip-protocol": 58
},
"icmpv6-match": {
"icmpv6-code": 0,
"icmpv6-type": 134
},

"openflowplugin-extension-general:extension-list": [
{
"extension-key": 
"openflowplugin-extension-nicira-match:nxm-nx-reg6-key",
"extension": {

"openflowplugin-extension-nicira-match:nxm-nx-reg": {
"reg": 
"nicira-match:nxm-nx-reg6",
"mask": 268435200,
"value": 1280
}
}
}
],
"ipv6-source": 
"fe80:0:0:0:f816:3eff:feb4:8492/128"
},
"cookie": 110100480,
"instructions": {
"instruction": [
{
"order": 0,
"apply-actions": {
"action": [
{
"order": 0,

"openflowplugin-extension-nicira-action:nx-resubmit": {
"table": 220
}
}
]
}
}
]
}
}
]
}
]

openstack@ubuntu:~$ flows
cookie=0x690, duration=221.163s, table=240, n_packets=0, n_bytes=0, 
priority=63010,icmp6,reg6=0x500/0xf00,ipv6_src=fe80::f816:3eff:feb4:8492,icmp_type=134,icmp_code=0
 actions=resubmit(,220)

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Karthikeyan
Sent: Tuesday, May 29, 2018 8:58 PM
To: Vishal Thapar 
Cc: Sridhar Alaparthi ; netvirt-dev 
; 
openflowplugin-dev@lists.opendaylight.org; Naveen Manyam Subramanyam 

Subject: Re: [openflowplugin-dev] OpenflowPlugin: Invalid length for IPv6 
Address in OXM field - Reg

Hi Vishal,

Please find below inventory config DS entry for the same.

http://192.168.56.1:8181/restconf/config/opendaylight-inventory:nodes


{
"id": 240,
"flow": [
{
"id": 
"Ingress_ICMPv6_392318374877_5_fa:16:3e:b4:84:92_134_LinkLocal_Permit_",
"priority": 63010,
"table_id": 240,
"hard-timeout": 0,
"installHw": true,
"match": {
"ethernet-match": {
"ethernet-type": {
"type": 34525
}
},
  

Re: [openflowplugin-dev] [OpenDaylight TSC] OpenFlowplugin Committer Nomination for Arun Prakash

[D Arunprakash]

Thanks, everyone for your support. Will continue to do my best and contribute 
to Openflowplugin.

Regards,
Arun

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Vishal 
Thapar
Sent: Wednesday, May 30, 2018 7:49 AM
To: Abhijit Kumbhare 
Cc:  ; Thanh Ha 
; openflowplugin-dev 

Subject: Re: [openflowplugin-dev] [OpenDaylight TSC] OpenFlowplugin Committer 
Nomination for Arun Prakash

Congrats Arun! Very well deserved.

On Wed, May 30, 2018 at 1:13 AM, Abhijit Kumbhare  wrote:
> So that is 9 votes - and it carries.
>
> Welcome & congrats Arun for being the newest committer on OpenFlow Plugin!
> Please work with the HelpDesk to get your committer rights assigned. 
> Also Anil - please update the project wiki to add Arun in the committer list.
>
> On Tue, May 29, 2018 at 11:52 AM, Thanh Ha 
> 
> wrote:
>>
>> On Thu, May 24, 2018 at 9:05 PM, Anil Vishnoi 
>> wrote:
>>>
>>> Dear TSC,
>>>
>>>
>>> Majority of OpenFlow plugin committers (5/6) voted in favor (and 
>>> none
>>> against) for Arunprakash's nomination as a committer to OpenFlow 
>>> plugin project. Arun has done significant contribution to 
>>> openflowplugin project in last 2 releases and played a very active 
>>> role in the project in terms of implementing new features, fixing 
>>> bugs[1], answering questions on dev list, review patches [2] and technical 
>>> discussion.
>>>
>>>
>>> I would like to bring the nomination to TSC for the approval, so 
>>> please hold a vote for confirming his nomination.
>>>
>>>
>>> [0]
>>> https://lists.opendaylight.org/pipermail/openflowplugin-dev/2018-May
>>> /008324.html
>>>
>>> [1]
>>> https://git.opendaylight.org/gerrit/#/q/author:%22d.arunprakash%2540
>>> ericsson.com%22+project:openflowplugin
>>>
>>> [2]
>>> https://git.opendaylight.org/gerrit/#/q/project:openflowplugin+revie
>>> wedby:%22d.arunprakash%2540ericsson.com%22
>>>
>>>
>>>
>>> --
>>> Thanks
>>> Anil
>>
>>
>> +1
>>
>> Thanh
>>
>> ___
>> TSC mailing list
>> t...@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/tsc
>>
>
>
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
>
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Openflow version negotiation during Handshake query

[D Arunprakash]

Hi Brady,
Even we are setting the protocol manually after creating the bridge. But there 
is a functionality available in openflowplugin which will negotiate the 
protocol version.

If we connect ovs2.8 and above, by default it sends HELLO message with Openflow 
1.4(It doesn’t sent bitmap with this message, bitmap will have details of the 
protocol versions supported by ovs).

Once plugin receives HELLO message with version higher than the supported 
version and if there is no bitmap, OFP send HELLO message with version 1.3 and 
bitmap (1.0, 1.3).

When this OF1.3 message hello message reaches OVS, it assumes that the 
negotiation went fine and makes the TCP channel connected.

But openflowplugin waits for the switch to send HELLO message with next lower 
version ie. 1.3 here.

Sequence diagram of the current handshake implementation:
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin::Sequence_Diagrams#Connection_Sequence_.28Handshake.29_Diagram

We wanted to know what is the expected behavior and how should be negotiation 
work between openflow switch and odl controller.


Regards,
Arun
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Brady 
Johnson
Sent: Friday, May 18, 2018 12:18 AM
To: Gobinath . 
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] Openflow version negotiation during Handshake 
query

Gobinath,

Im not sure if ODL should automatically negotiate this during the initial 
capability negotiations. Ive seen similar problems with OVS 2.8 and 2.9, and 
when I manually create the bridge, I had to do the following:

$ sudo ovs-vsctl add-br br0
$ sudo ovs-vsctl set bridge br0 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13

Or, when creating the bridge from ODL, the following:

public ListenableFuture createOvsBridge(IpAddress ovsMgrIp, String 
ovsBridgeName) {
OvsdbBridgeAugmentationBuilder ovsBridge = new 
OvsdbBridgeAugmentationBuilder();
ovsBridge.setBridgeName(new OvsdbBridgeName(ovsBridgeName));
ovsBridge.setProtocolEntry(Arrays.asList(
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow10.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow11.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow12.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow13.class).build()));
ovsBridge.setManagedBy(new 
OvsdbNodeRef(InstanceIdentifier.create(NetworkTopology.class)
.child(Topology.class, new 
TopologyKey(SouthboundConstants.OVSDB_TOPOLOGY_ID))
.child(Node.class, new NodeKey(new 
NodeId(createNodeIdStr(ovsMgrIp));

NodeBuilder ovsBridgeNode = new NodeBuilder();
ovsBridgeNode.addAugmentation(OvsdbBridgeAugmentation.class, 
ovsBridge.build());
ovsBridgeNode.setNodeId(new NodeId(createNodeIdStr(ovsMgrIp, 
ovsBridgeName)));
ovsBridgeNode.setKey(new NodeKey(ovsBridgeNode.getNodeId()));




Regards,

Brady Johnson
bjohn...@inocybe.ca


[http://www.inocybe.com/wp-content/uploads/2014/09/default-login-image.png]

[https://lh5.googleusercontent.com/4bsvmVYKzg5a_jM7_OOqbLXBSi8HbyuNfXuS5cO9eUpXgLzSUKrmdqdSOFmdShqIg0hX4xUHo2nYSUAlBC7KRnN3-COAkcx0CLOUEQrHCx9TVrQ2-0MP_qR0XpR22Kc8sdAQzZc1][https://lh3.googleusercontent.com/mkQzuX53_XbTrmTqeiS_gh2tauU4wJ_poqn7v-NSdKZoLI0jbWxdIIhrHZh7rSB-xpU7e2SqYDhcNfE8-rxzlQn15KaqJ9BqWOl65BakoHsKrbcCMhcdsnyrJAVuUV5SIFoazHIr][https://lh3.googleusercontent.com/Nzy3ZqITNZfRZ_hT9N3dh7K8ow5sF68e-qmL_5CFjka1oWK2XSfPZOUN6S9gp9k84l1KWTwDPCOb2Vbh0Oi6pVm4Nl7IpXp1QrTI6gkLNcWtMNpHMq2o2CxCfgqTPDA6pKBxNwhY][Screenshot
 2017-02-14 at 10.43.55 
AM.png]



On Thu, May 17, 2018 at 6:52 AM, Gobinath . 
> wrote:
Hi All,

We tried to connect the OVS2.8.2 with the ODL controller. Though the TCP 
connection is established b/w the OVS and the controller, the connected node 
was not present in the DS.

The issue seem to be due to incomplete handshake b/w the switch and the 
controller. This issue in handshake is due to the following :

By default the Openflow version in OVS2.8.2 switches are OF1.4.

Since OF1.4 not supported by the controller, version negotiation process takes 
place to agree on a OF version wherein


a)   If the HELLO msg sent by the switch has version bitmap(field 
containing info about support for all the OF versions), the negotiation is done 
in a single step with the highest version supported by 

[openflowplugin-dev] Autorelease build failing while adding dependency on genius-srm from openflowplugin

[D Arunprakash]

Hello,
We are trying to use the genius service recovery framework(srm-api) from 
openflowplugin.
https://git.opendaylight.org/gerrit/#/c/68998/

Since, odl-genius-srm was exposed as an independent feature and srm-api doesn't 
dependent on ofp, we didn't find any issues during compiling or feature install.

But the autorelease validate jenkin build always failing with the below error.

https://jenkins.opendaylight.org/releng/job/openflowplugin-validate-autorelease-fluorine/81/console

09:17:41 + ./scripts/determine-merge-order.py
09:17:42 Traceback (most recent call last):
09:17:42   File "./scripts/determine-merge-order.py", line 80, in 
09:17:42 determine_merge_order()
09:17:42   File "./scripts/determine-merge-order.py", line 68, in 
determine_merge_order
09:17:42 for d in deps_order:
09:17:42   File 
"/w/workspace/openflowplugin-validate-autorelease-fluorine/venv/lib/python2.7/site-packages/networkx/algorithms/dag.py",
 line 197, in topological_sort
09:17:42 raise nx.NetworkXUnfeasible("Graph contains a cycle or graph 
changed "
09:17:42 networkx.exception.NetworkXUnfeasible: Graph contains a cycle or graph 
changed during iteration
09:17:42 Build step 'Execute shell' marked build as failure
09:17:42 $ ssh-agent -k


Could you please let us know if the feature exposed from genius is proper or 
jenkin autorelease script detect the circular dependency, even though the 
odl-genius-srm doesn't dependent on ofp.
Regards,
Arun
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

[D Arunprakash]

I have raised a review to modify ip-address to ip-address-no-zone.

https://git.opendaylight.org/gerrit/#/c/71068/

We can merge whichever is appropriate.

Regards,
Arun

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Wednesday, April 18, 2018 2:03 PM
To: D Arunprakash <d.arunprak...@ericsson.com>; 
integration-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; Tom 
Pantelis <tompante...@gmail.com>
Cc: openflowplugin-dev@lists.opendaylight.org; Anil Vishnoi 
<vishnoia...@gmail.com>
Subject: Re: Build breakage in openflowplugin due IP address NoZone changes

On 18/04/18 08:09, D Arunprakash wrote:
> Hello,
> 
> The following review in mdsal might have impacted openflowplugin 
> functionality.
> 
> https://git.opendaylight.org/gerrit/#/c/70769/

Sorry about that.

> https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verif
> y-fluorine-mvn33-openjdk8/259/console
> 
>  
> 
> org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.typ
> es.rev130715.Ipv4Address<Ipv4Address{_value=0.1.2.3}>
> but was:
> org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.typ
> es.rev130715.Ipv4AddressNoZone<Ipv4Address{_value=0.1.2.3}>
> 
> is it new expectation on openflowplugin to change from Ipv4Address to 
> Ipv4AddressNoZone ?

There are two aspects to this.

As an interim, the codecs from wire need to be updated to convert 
Ipv4AddressNoZone to Ipv4Address, so that equality works as expected and the 
breakage is recovered -- https://git.opendaylight.org/gerrit/71072
does that.

Going forward, though, I believe the openflow models need to be updated to 
require ipv4-address-no-zone rather than ipv4-address (and same goes for 
ip-address and ipv6-address). This really is the correct thing to do
-- ipv4-address is not really the IPv4 address used in OpenFlow protocol.

Regards,
Robert

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

[openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

[D Arunprakash]

Hello,
The following review in mdsal might have impacted openflowplugin functionality.
https://git.opendaylight.org/gerrit/#/c/70769/


https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn33-openjdk8/259/console

org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev130715.Ipv4Address
 but was: 
org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev130715.Ipv4AddressNoZone


is it new expectation on openflowplugin to change from Ipv4Address to 
Ipv4AddressNoZone ?

Regards,
Arun
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] PortReason Flag not set properly during port deletes

[D Arunprakash]

Patch merged in master, please run csit on the genius patch and let us know the 
results.

Regards,
Arun

From: Faseela K
Sent: Tuesday, April 10, 2018 2:07 PM
To: D Arunprakash <d.arunprak...@ericsson.com>; Suja T <suj...@ericsson.com>; 
openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
Cc: genius-...@lists.opendaylight.org; odl netvirt dev 
<netvirt-...@lists.opendaylight.org>
Subject: RE: PortReason Flag not set properly during port deletes

Hi Arun,
  Any update on this? :)
Thanks,
Faseela

From: D Arunprakash
Sent: Monday, April 02, 2018 3:03 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Suja T 
<suj...@ericsson.com<mailto:suj...@ericsson.com>>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Hi Faseela,
Waiting for openflowplugin committers to review and merge.

https://git.opendaylight.org/gerrit/#/c/69422/

Will discuss in today's community meeting and close.

Regards,
Arun

From: Faseela K
Sent: Monday, April 02, 2018 12:52 PM
To: D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; Suja T 
<suj...@ericsson.com<mailto:suj...@ericsson.com>>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Arun,
  Can we get the patch merged, and then get cherry-picked to Oxygen?
  We are waiting for this, to get the dependent patches in genius to be merged.
Thanks,
Faseela

From: D Arunprakash
Sent: Thursday, March 15, 2018 5:05 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Suja T 
<suj...@ericsson.com<mailto:suj...@ericsson.com>>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Hi Faseela,
Have raised a tentative patch for the issue, could you please check and let us 
know if it's working as expected.
https://git.opendaylight.org/gerrit/#/c/69422/

Regards,
Arun

From: Faseela K
Sent: Thursday, March 15, 2018 4:51 PM
To: Suja T <suj...@ericsson.com<mailto:suj...@ericsson.com>>; D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Hi,
   I have raised the below JIRA to track the issue :
  https://jira.opendaylight.org/browse/OPNFLWPLUG-987

Thanks,
Faseela

From: Faseela K
Sent: Tuesday, March 13, 2018 7:56 AM
To: Suja T <suj...@ericsson.com<mailto:suj...@ericsson.com>>; D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 'genius-...@lists.opendaylight.org' 
<genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>>; 
'odl netvirt dev' 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Suja,
   We have reverted the changes to use PortReason flag in master as well, as 
the current implementation is buggy and we have tests failing because of that.
Thanks,
Faseela

From: Faseela K
Sent: Saturday, March 10, 2018 1:31 AM
To: Suja T <suj...@ericsson.com<mailto:suj...@ericsson.com>>; D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 'genius-...@lists.opendaylight.org' 
<genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>>; 
'odl netvirt dev' 
&

Re: [openflowplugin-dev] Doubt on openflow reconciliation logic

[D Arunprakash]

If you enable bundle reconciliation, then all the groups and flows will be 
deleted before pushing the new flows and groups. Otherwise, normal 
reconciliation will just replace the old flows and groups and won’t do any 
cleanup.

There is no table specific flow deletion in resync.

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Josh 
Hershberg
Sent: Tuesday, April 10, 2018 1:12 PM
To: Faseela K 
Cc: coe-...@lists.opendaylight.org; openflowplugin-dev 

Subject: Re: [openflowplugin-dev] Doubt on openflow reconciliation logic

As far as I can tell from 
...openflowplugin.applications.frm.impl.FlowNodeReconciliationImpl#createMessages
 the first thing done during reconciliation is that all flows and groups are 
deleted. Although bundles are not yet implemented for upgrade, the plan is to 
also remove all flows and groups as the first action in the bundle. :-(

On Tue, Apr 10, 2018 at 10:29 AM, Faseela K 
> wrote:
Hi openflowplugin-devs,
In COE, we have a usecases where we need to manage one flow table on a 
bridge, outside ODL.
However there are several other flow tables on the same bridge which is 
managed by ODL as well.
1.  What will be the behavior of resync in such a case? Will ODL wipe off 
all the flows in the bridge, or will it delete only tables owned by ODL?
2.  What will happen in case of ODL upgrade?
Thanks,
Faseela

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] PortReason Flag not set properly during port deletes

[D Arunprakash]

Hi Faseela,
Waiting for openflowplugin committers to review and merge.

https://git.opendaylight.org/gerrit/#/c/69422/

Will discuss in today's community meeting and close.

Regards,
Arun

From: Faseela K
Sent: Monday, April 02, 2018 12:52 PM
To: D Arunprakash <d.arunprak...@ericsson.com>; Suja T <suj...@ericsson.com>; 
openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
Cc: genius-...@lists.opendaylight.org; odl netvirt dev 
<netvirt-...@lists.opendaylight.org>
Subject: RE: PortReason Flag not set properly during port deletes

Arun,
  Can we get the patch merged, and then get cherry-picked to Oxygen?
  We are waiting for this, to get the dependent patches in genius to be merged.
Thanks,
Faseela

From: D Arunprakash
Sent: Thursday, March 15, 2018 5:05 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Suja T 
<suj...@ericsson.com<mailto:suj...@ericsson.com>>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Hi Faseela,
Have raised a tentative patch for the issue, could you please check and let us 
know if it's working as expected.
https://git.opendaylight.org/gerrit/#/c/69422/

Regards,
Arun

From: Faseela K
Sent: Thursday, March 15, 2018 4:51 PM
To: Suja T <suj...@ericsson.com<mailto:suj...@ericsson.com>>; D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Hi,
   I have raised the below JIRA to track the issue :
  https://jira.opendaylight.org/browse/OPNFLWPLUG-987

Thanks,
Faseela

From: Faseela K
Sent: Tuesday, March 13, 2018 7:56 AM
To: Suja T <suj...@ericsson.com<mailto:suj...@ericsson.com>>; D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 'genius-...@lists.opendaylight.org' 
<genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>>; 
'odl netvirt dev' 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Suja,
   We have reverted the changes to use PortReason flag in master as well, as 
the current implementation is buggy and we have tests failing because of that.
Thanks,
Faseela

From: Faseela K
Sent: Saturday, March 10, 2018 1:31 AM
To: Suja T <suj...@ericsson.com<mailto:suj...@ericsson.com>>; D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 'genius-...@lists.opendaylight.org' 
<genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>>; 
'odl netvirt dev' 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Just an FYI.
Suja was later on able to reproduce the issue, with some openflowplugin logs 
enabled.
@Suja : Please update if you have some conclusion on the root cause.

Thanks,
Faseela

From: Faseela K
Sent: Friday, March 09, 2018 12:31 PM
To: Suja T <suj...@ericsson.com<mailto:suj...@ericsson.com>>; D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>
Subject: RE: PortReason Flag not set properly during port deletes

Suja,

   The logs which you have referred somehow gets these test cases passing, and 
that is when Reason flag is coming properly. If you check the run below where 
the test-case fails, you can see the PortReason flag coming as "Update".


https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-oxygen/50/odl_1/odl1_karaf.log.gz
  ==&

Re: [openflowplugin-dev] New Openflow meeting time

[D Arunprakash]

+1, I’m okay with the new timings.

From: Hema Gopalkrishnan
Sent: Monday, March 26, 2018 10:34 AM
To: Shuva Kar <shuva.jyoti.kar...@gmail.com>; Abhijit Kumbhare 
<abhijitk...@gmail.com>
Cc: Anil Vishnoi <vishnoia...@gmail.com>; Jozef Bacigál 
<jozef.baci...@pantheon.tech>; D Arunprakash <d.arunprak...@ericsson.com>; Luis 
Gomez Palacios <ece...@gmail.com>; Sunil Kumar G <sunil.g.ku...@ericsson.com>; 
Bertrand Low <bertrand@hcl.com>; Gobinath . <gobin...@ericsson.com>; 
Prasanna Huddar <prasanna.hud...@ericsson.com>; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: New Openflow meeting time

Hi Anil,
  I am fine with the change of time to 8:30 AM PST ,which will be 9 PM IST.

When the time changes again, it gets a little late here 10 to 11 PM IST. We can 
re consider the meeting time then.

Regards
Hema

From: Shuva Kar [mailto:shuva.jyoti.kar...@gmail.com]
Sent: 26 March 2018 02:49
To: Abhijit Kumbhare <abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>>
Cc: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>; Jozef 
Bacigál <jozef.baci...@pantheon.tech<mailto:jozef.baci...@pantheon.tech>>; D 
Arunprakash <d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
Luis Gomez Palacios <ece...@gmail.com<mailto:ece...@gmail.com>>; Sunil Kumar G 
<sunil.g.ku...@ericsson.com<mailto:sunil.g.ku...@ericsson.com>>; Bertrand Low 
<bertrand@hcl.com<mailto:bertrand@hcl.com>>; Gobinath . 
<gobin...@ericsson.com<mailto:gobin...@ericsson.com>>; Prasanna Huddar 
<prasanna.hud...@ericsson.com<mailto:prasanna.hud...@ericsson.com>>; Hema 
Gopalkrishnan 
<hema.gopalkrish...@ericsson.com<mailto:hema.gopalkrish...@ericsson.com>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: New Openflow meeting time

Am good with the time change to 0830 AM PST
On Mon 26 Mar, 2018, 02:39 Abhijit Kumbhare, 
<abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>> wrote:
Fine with me.

On Sun, Mar 25, 2018 at 2:07 PM, Anil Vishnoi 
<vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> wrote:
Hi All,

As discuss in the last meeting, because of the DST change, present meeting time 
is not convenient for many committers. I am planning to move it to our old 
meeting time 8:30 AM PST. Please let me know if this time slot works for you or 
if you have any other time-slot suggestion. If you want me to start doodle-poll 
on few time slot that covers APAC, Europe and US region, please let me know.

iPhone.iTypos.iApologize

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [genius-dev] Openflow Service ERROR state in Fluorine

[D Arunprakash]

Hi Sathwik,
We have merged the below patch and it should fix this issue.

https://git.opendaylight.org/gerrit/#/c/69657/

Regards,
Arun
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Michael 
Vorburger
Sent: Tuesday, March 20, 2018 6:36 PM
To: B Sathwik ; infrautils-...@lists.opendaylight.org
Cc: genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [genius-dev] Openflow Service ERROR state in 
Fluorine

+infrautils-dev:

On Tue, Mar 20, 2018 at 1:33 PM, B Sathwik 
> wrote:
I have raised a bug for this. Here is the JIRA link

https://jira.opendaylight.org/browse/OPNFLWPLUG-988

Regards
Sathwik
From: B Sathwik
Sent: Tuesday, March 20, 2018 12:34 PM
To: 
openflowplugin-dev@lists.opendaylight.org
Cc: genius-...@lists.opendaylight.org
Subject: Openflow Service ERROR state in Fluorine

Hi

Genius CSIT for fluorine is failing because Openflow service is in ERROR state 
in diag status CLI output, where as it is passing for Oxygen.

https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-fluorine/

I tried it locally with fluorine distribution. Here is the output

opendaylight-user@root>
opendaylight-user@root>showSvcStatus
Timestamp: Tue Mar 20 11:53:31 IST 2018
Node IP Address: 127.0.0.1
System ready state: ACTIVE
  OPENFLOW: ERROR
  IFM : OPERATIONAL
  ITM : OPERATIONAL
  DATASTORE   : OPERATIONAL
opendaylight-user@root>
opendaylight-user@root>

seeing this gives me an idea for an Enhancement, in the infrautils diagstatus 
code: What I think one would ideally want to see in this output, both on the 
CLI as well as when used e.g. from a CSIT script via JMX, to avoid having to 
dig through logs, is WHY something is in Error... so ideally, it should 
probably be possible to DiagStatusService report() not just a ServiceState in a 
ServiceDescriptor, but a Throwable to diagstatus, which would set the status to 
ERROR - and then the CLI/JMX/etc. could include that Throwable as more detailed 
background about the failure. The code catching exceptions and setting an ERROR 
ServiceState would then pass that Throwable to the ServiceDescriptor. In this 
particular case, the NPE that was apparently fixed by c/69657 would then show 
up there - which would probably help, in the future, to see the real problem 
more immediately.

Would anyone be motivated to work on this? A new JIRA in the infrautils project 
would be a good start.

Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com | IRC: vorburger @freenode | 
~ = http://vorburger.ch



Can someone from openflowplugin team look into this issue?

Best Regards
Sathwik


___
genius-dev mailing list
genius-...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/genius-dev

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [release] Autorelease fluorine failed to build openflowplugin from openflowplugin

[D Arunprakash]

Hi Michael,
We have merged one patch https://git.opendaylight.org/gerrit/#/c/69473/ which 
is moving to the new toString format and will take care of the failing TCs.

I have also raised one more patch 
https://git.opendaylight.org/gerrit/#/c/69486/ to remove the toString 
dependency on TCs and assert on values.

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Michael 
Vorburger
Sent: Wednesday, March 14, 2018 3:23 PM
To: openflowplugin-dev 
Cc: mdsal-...@lists.opendaylight.org; release (rele...@lists.opendaylight.org) 

Subject: Re: [openflowplugin-dev] [release] Autorelease fluorine failed to 
build openflowplugin from openflowplugin

Hello openflowpluguineans, and just FYI mdsal-dev:

On Wed, Mar 14, 2018 at 2:42 AM, Jenkins 
> 
wrote:
Attention openflowplugin-devs,

Autorelease fluorine failed to build openflowplugin from openflowplugin in build
16. Attached is a snippet of the error message related to the
failure that we were able to automatically parse as well as console logs.


Console Logs:
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-fluorine/16

Jenkins Build:
https://jenkins.opendaylight.org/releng/job/autorelease-release-fluorine/16/

Please review and provide an ETA on when a fix will be available.

Thanks,
ODL releng/autorelease team


Failed tests:

  PacketOutConvertorTest.toPacketOutInputAllParmTest:176 expected: but was:

this looks like yet another impact of some toString() change which must have 
recently gone into mdsal... we dealt with something like this in genius a few 
days ago, and this may help you to fix it in the same way:

https://git.opendaylight.org/gerrit/#/c/69375/1/itm/itm-impl/src/test/java/org/opendaylight/genius/itm/tests/xtend/ExpectedExternalTunnelObjects.xtend

https://lists.opendaylight.org/pipermail/genius-dev/2018-March/002465.html

but if I were you ideally I would not just fix the String but change the test 
to not rely on toString but to get that value (and perhaps and instanceof, if 
there are other things than PortNumber possible)? I'm happy to review such a 
change if you like.

Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com | IRC: vorburger @freenode | 
~ = http://vorburger.ch
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Approaches for making budle service more generic (normal resync and upgrade resync being special cases)

[D Arunprakash]

Last week’s discussion on reconciliation/upgrade profiles,

1. There shall be two profiles/modes configured which can change OFP behavior 
in context of reconciliation

   Reconciliation Mode : 

   AUTONOMOUS mode implies that OFPlugin shall perform reconciliation 
autonomously as it does now without any change in the workflow - ie. Switch-
   connection-handling followed by bundle-based Reconciliaion execution 
followed by publishing of switch to the Inventory Opertaional DS

   ARBITRATED mode implies that OFPlugin shall not execute reconciliation by 
itself but by allowing higher level app "Reconciliation arbiter / orchestrator" 
to initiate and
   complete the bundle-based reconciliation including any error-handling thereof

2. This implies two changes for OFPlugin
   a) OFP must publish the switch to Inventory Operational soon after the 
connection-handling and master-election phases complete without triggering 
Reconciliation by
   itself in ARBITRATED mode
   b) OFP must expose RPCs to start, modify and close bundle so that 
"Reconciliation arbiter / orchestrator" is able to invoke the same to realize 
reconciliation

Reconciliation Arbiter / Orchestrator (which is functional only in scenario 
when Reconciliation-Mode==ARBITRATED)

Listeners for Reconciliation Arbiter / Orchestrator :
This is more or less similar to current reconciliation function of FRM
   a) Inventory Oper DTCN for switch status sensing
   b) Config Inventory DTCN for flows / groups and meters

Conditions:

a) Whether or not data is available for given switch in Config Inventory DS
b) Whether the system is in upgrade mode

Common reaction for Switch Connection handling when
- Condition 1 : UPGRADE_MODE=true
- Condition 2 : UPGRADE_MODE=false
For all conditions, reconciliation can be executed by the arbiter as per below 
steps

Trigger reconciliation by
 a) Issuing implicit close of implicit bundle-id - this is mainly to 
address following failure scenario in OF-HA context : For OFHA purge the 
incomplete implicit bundles
 which might have been started by previous switch-master in case 
leadership changes. Since we use a single implicit bundle-id, issuing a 
cancel-bundle from new
 switch-master implicitly would not result in any issues and can be 
considered as safety measure.
 b) starting implicit bundle using OFP RPC
 b) reading flows / groups / meters from DS if present
 c) add the same to the implicit bundle if available
 d) defer the bundle close for a period of time (which is not a timer 
managed by OFP but by some static configuration managed within the scope of
 Reconciliation arbiter / orchestrator
 e) During the deferred period - if any flows / group / meter 
configurations are received via Inventory Config DTCN, arbiter shall push those 
flows to current bundle
 f) When timer expires, issue bundle closure OFP RPC call to all 
switches in one close loop

Other key decisions :
1) Since we switch-agnostic implicit bundle inventory data model need not be 
changed and that kind of change reuqires a more rigorous impact-assessment and 
can be taken up in future


Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Josh 
Hershberg
Sent: Wednesday, February 28, 2018 1:26 PM
To: Anil Vishnoi 
Cc: Dayavanti Gopal Kamath ; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] Approaches for making budle service more 
generic (normal resync and upgrade resync being special cases)

A few comments inline...

On Tue, Feb 27, 2018 at 10:58 PM, Anil Vishnoi 
> wrote:
Hi Muthu,

Sorry for delayed response. Please see inline ..

On Fri, Feb 23, 2018 at 2:44 AM, Muthukumaran K 
> wrote:
Hi all,

@Arun, @Gobi, please feel free to add anything which I might have missed out 
from our discussions

Context :
===
During last OFPlugin weekly call, we were discussing about how bundle-based 
resync flow would behave in upgrade context. In normal resync scenarios – ie. 
a) switch reconnecting and/or b) controller reboots (and subsequent switch 
reconnects), flows and groups which can be dispatched via resync bundle is 
sourced from the inventory Config DS. In case of upgrade, inventory Config DS 
would be completely nuked and hence a different handling is required. During 
this discussion, a concern was raised as to why OFPlugin should become 
extensively cognizant of “upgrade” as  a special case. The thought process was 
more to expose the bundle service generically from OFPlugin’s end so that 
upgrade-orchestration becomes a higher level functionality 

Re: [openflowplugin-dev] FYI :Builds are failing due to LLDPTLV failure

[D Arunprakash]

Hi Nidhi,
There were multiple reviews merged in master yesterday, you might have seen 
this issue in the middle.

Could you please let us know if you are still facing the issue?

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Nidhi 
Adhvaryu
Sent: Tuesday, March 06, 2018 5:32 PM
To: genius-...@lists.opendaylight.org
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: [openflowplugin-dev] FYI :Builds are failing due to LLDPTLV failure

Hi,

Feature install in genius throwing some errors regarding LLDPTLV.

It looks like some merges are causing this problem.

Thanks,
Nidhi Adhvaryu
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

[openflowplugin-dev] stable/carbon: config parent 0.6.3-SNAPSHOT version missing from nexus https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/controller/config

[D Arunprakash]

Hello,
Openflowplugin carbon review Jenkins build is failing saying config parent 
snapshot is missing in nexus, could you please help us in fixing this?

https://git.opendaylight.org/gerrit/#/c/67771/

06:36:28 [ERROR] [ERROR] Some problems were encountered while processing the 
POMs:
06:36:28
[FATAL] Non-resolvable parent POM for 
org.opendaylight.openflowplugin.applications:inventory-manager:0.4.3-SNAPSHOT: 
Could not find artifact 
org.opendaylight.controller:config-parent:pom:0.6.3-SNAPSHOT in 
opendaylight-snapshot 
(https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/) 
and 'parent.relativePath' points at no local POM @ line 4, column 11


I wanted to debug one of the csit failure, so need the jenkins build to be 
running.

Regards,
Arun
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] is dhcp issue fixed on carbon?

[D Arunprakash]

The tunnel port tun21356a38e88 on controller node is missing in the inventory.

From the logs, we can see the tunnel port addition was received at 2018-01-31 
01:34:42,353. And the same has been submitted to inventory at 01:34:42,354, but 
there is an ERROR while submitting the transaction.

2018-01-31 01:34:42,353 | DEBUG | entLoopGroup-7-1 | DeviceContextImpl  
  | 280 - org.opendaylight.openflowplugin.impl - 0.4.3.SNAPSHOT | 
writePortStatusMessage for port  PortStatusMessage 
[_advertisedFeatures=PortFeatures [__10mbHd=false, __10mbFd=false, 
__100mbHd=false, __100mbFd=false, __1gbHd=false, __1gbFd=false, __10gbFd=false, 
__40gbFd=false, __100gbFd=false, __1tbFd=false, _other=false, _copper=false, 
_fiber=false, _autoneg=false, _pause=false, _pauseAsym=false], 
_config=PortConfig [_portDown=false, _noRecv=false, _noFwd=false, 
_noPacketIn=false], _currSpeed=0, _currentFeatures=PortFeatures 
[__10mbHd=false, __10mbFd=false, __100mbHd=false, __100mbFd=false, 
__1gbHd=false, __1gbFd=false, __10gbFd=false, __40gbFd=false, __100gbFd=false, 
__1tbFd=false, _other=false, _copper=false, _fiber=false, _autoneg=false, 
_pause=false, _pauseAsym=false], _hwAddr=MacAddress [_value=ca:ab:ee:bd:80:0f], 
_maxSpeed=0, _name=tun21356a38e88, _peerFeatures=PortFeatures [__10mbHd=false, 
__10mbFd=false, __100mbHd=false, __100mbFd=false, __1gbHd=false, __1gbFd=false, 
__10gbFd=false, __40gbFd=false, __100gbFd=false, __1tbFd=false, _other=false, 
_copper=false, _fiber=false, _autoneg=false, _pause=false, _pauseAsym=false], 
_portNo=9, _reason=OFPPRADD, _state=PortState [_linkDown=false, _blocked=false, 
_live=false], _supportedFeatures=PortFeatures [__10mbHd=false, __10mbFd=false, 
__100mbHd=false, __100mbFd=false, __1gbHd=false, __1gbFd=false, __10gbFd=false, 
__40gbFd=false, __100gbFd=false, __1tbFd=false, _other=false, _copper=false, 
_fiber=false, _autoneg=false, _pause=false, _pauseAsym=false], _version=4, 
_xid=0, augmentation=[]]

2018-01-31 01:34:42,354 | WARN  | entLoopGroup-7-1 | DeviceContextImpl  
  | 280 - org.opendaylight.openflowplugin.impl - 0.4.3.SNAPSHOT | submit 
transaction for write port status message


2018-01-31 01:34:42,355 | WARN  | t-dispatcher-224 | ConcurrentDOMDataBroker
  | 184 - org.opendaylight.controller.sal-distributed-datastore - 
1.5.3.SNAPSHOT | Tx: DOM-CHAIN-10-2 Error during phase CAN_COMMIT, starting 
Abort
TransactionCommitFailedException{message=Data did not pass validation., 
errorList=[RpcError [message=Data did not pass validation., severity=ERROR, 
errorType=APPLICATION, tag=operation-failed, applicationTag=null, info=null, 
cause=org.opendaylight.yangtools.yang.data.api.schema.tree.ModifiedNodeDoesNotExistException:
 Node 
/(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:883083145531}]/AugmentationIdentifier{childNames=[(urn:opendaylight:flow:inventory?revision=2013-08-19)port-number,
 (urn:opendaylight:flow:inventory?revision=2013-08-19)stale-group, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)supported-match-types, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)table, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)group, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)manufacturer, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)software, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)ip-address, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)serial-number, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)table-features, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)supported-actions, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)hardware, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)description, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)switch-features, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)supported-instructions, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)stale-meter, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)meter]}/(urn:opendaylight:flow:inventory?revision=2013-08-19)table/table[{(urn:opendaylight:flow:inventory?revision=2013-08-19)id=50}]/flow
 does not exist. Cannot apply modification to its children.]]}

Transaction chain was failed to submit due to the above error and it shows that 
it was trying to add/update the flow for table id 50 to the inventory.
Since we have disabled statistics in this run, this error is not expected to 
come. 

We are analyzing the logs further.
 
@Anil Vishnoi,  do you have an idea why this error comes even though the 
statistics is disabled?

Regards,
Arun

-Original Message-
From: Jamo Luhrsen [mailto:jluhr...@gmail.com] 
Sent: Wednesday, January 31, 2018 10:01 AM
To: D Arunprakash <d.arunprak...@ericsson.com>; Jamo Luhrsen 
<jluhr...@redhat.com>; Sam Hague <sha...@redhat.com>
Cc: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; Manu B 
<man..

Re: [openflowplugin-dev] is dhcp issue fixed on carbon?

[D Arunprakash]

Hi Jamo,
I just had an initial look on Thursday and the test cases was failed for 
different and didn’t get a chance to look over the long weekend. 
Today I don’t find the link working anymore, Could you please retrigger with 
packet capture enabled?

Regards,
Arun 
-Original Message-
From: Jamo Luhrsen [mailto:jluhr...@redhat.com] 
Sent: Thursday, January 25, 2018 12:45 PM
To: D Arunprakash <d.arunprak...@ericsson.com>; Jamo Luhrsen 
<jluhr...@gmail.com>; Sam Hague <sha...@redhat.com>
Cc: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; Manu B 
<man...@ericsson.com>
Subject: Re: [openflowplugin-dev] is dhcp issue fixed on carbon?

my bad. I fixed the problem.

this job should be better:

https://jenkins.opendaylight.org/sandbox/job/netvirt-csit-1node-openstack-ocata-jamo-upstream-stateful-carbon/12/

Thanks,
JamO

On 1/24/18 11:01 PM, D Arunprakash wrote:
> Hi Jamo,
> All the TCs are failed, please check.
> 
> Seems to be basic issue,
> 
> ===
> Message:  Parent suite setup failed:
> No keyword with name 
> 'KarafKeywords.Execute_Controller_Karaf_Command_On_Background log:set TRACE 
> org.opendaylight.openflowplugin.impl' found.
> ===
> 
> Regards,
> Arun
> 
> -Original Message-
> From: Jamo Luhrsen [mailto:jluhr...@gmail.com]
> Sent: Thursday, January 25, 2018 11:21 AM
> To: D Arunprakash <d.arunprak...@ericsson.com>; Sam Hague 
> <sha...@redhat.com>
> Cc: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; 
> Manu B <man...@ericsson.com>; Jamo Luhrsen <jluhr...@redhat.com>
> Subject: Re: [openflowplugin-dev] is dhcp issue fixed on carbon?
> 
> I didn't add any extra tcpdump yet, but here is a job that will enable TRACE 
> for ofp.impl.
> 
> it's only running the four connectivity/ folder suites.
> 
> https://jenkins.opendaylight.org/sandbox/job/netvirt-csit-1node-openst
> ack-ocata-jamo-upstream-stateful-carbon/11/
> 
> JamO
> 
> 
> On 1/24/18 8:04 PM, D Arunprakash wrote:
>> Please enable the logs for the below package,
>>
>> org.opendaylight.openflowplugin.impl
>>
>> Regards,
>>
>> Arun
>>
>> *From:*Sam Hague [mailto:sha...@redhat.com]
>> *Sent:* Thursday, January 25, 2018 9:32 AM
>> *To:* D Arunprakash <d.arunprak...@ericsson.com>
>> *Cc:* Anil Vishnoi <vishnoia...@gmail.com>; openflowplugin-dev 
>> <openflowplugin-dev@lists.opendaylight.org>; Vishal Thapar 
>> <vishal.tha...@ericsson.com>; Faseela K <faseel...@ericsson.com>; 
>> Josh Hershberg <jhers...@redhat.com>; Jamo Luhrsen 
>> <jluhr...@redhat.com>; Manu B <man...@ericsson.com>
>> *Subject:* RE: is dhcp issue fixed on carbon?
>>
>> What logs to enable? Or just the whole openflowplugin, which is very noisy.
>>
>> Is packet capture on port 6653 good?
>>
>> On Jan 24, 2018 10:54 PM, "D Arunprakash" <d.arunprak...@ericsson.com 
>> <mailto:d.arunprak...@ericsson.com>> wrote:
>>
>>  Hi Sam,
>>
>>  We need to enable Openflowplugin logs and do packet capture for the
>>  time window when the tunnel port is delete and added back.
>>
>>  Regards,
>>
>>  Arun
>>
>>  *From:*Anil Vishnoi [mailto:vishnoia...@gmail.com
>>  <mailto:vishnoia...@gmail.com>]
>>  *Sent:* Thursday, January 25, 2018 1:17 AM
>>  *To:* Sam Hague <sha...@redhat.com <mailto:sha...@redhat.com>>
>>  *Cc:* D Arunprakash <d.arunprak...@ericsson.com
>>  <mailto:d.arunprak...@ericsson.com>>; openflowplugin-dev
>>  <openflowplugin-dev@lists.opendaylight.org
>>  <mailto:openflowplugin-dev@lists.opendaylight.org>>; Vishal Thapar
>>  <vishal.tha...@ericsson.com <mailto:vishal.tha...@ericsson.com>>;
>>  Faseela K <faseel...@ericsson.com <mailto:faseel...@ericsson.com>>;
>>  Josh Hershberg <jhers...@redhat.com <mailto:jhers...@redhat.com>>;
>>  Jamo Luhrsen <jluhr...@redhat.com <mailto:jluhr...@redhat.com>>;
>>  Manu B <man...@ericsson.com <mailto:man...@ericsson.com>>
>>
>>
>>  *Subject:* Re: is dhcp issue fixed on carbon?
>>
>>  Hi Sam,
>>
>>  Looks like Arun is looking at it ?
>>
>>  Arun, if you are not looking at it currently, please let me know I
>>  will take a look at it.
>>
>>  Thanks
>>
>>  Anil
>>
>>  On Wed, Jan 24, 2018 at 4:25 AM, Sam Hague <sha...@redhat.com
>>  <mailto:sha...@redhat.com>> 

Re: [openflowplugin-dev] [release] Autorelease nitrogen failed to build odl-openflowplugin-southbound from openflowplugin

[D Arunprakash]

Hi Anil,
Each build is failing with different reason and the latest build 
https://jenkins.opendaylight.org/releng/job/autorelease-release-nitrogen/375/ 
passed without any error.

And the previous one 374 failed in odl-unimgr,

22:26:27 [INFO] --- maven-surefire-plugin:2.18.1:test (default) @ 
odl-unimgr-netvirt ---
22:26:27 [INFO] Surefire report directory: 
/w/workspace/autorelease-release-nitrogen/unimgr/features/odl-unimgr-netvirt/target/surefire-reports
22:26:27
22:26:27 ---
22:26:27  T E S T S
22:26:27 ---
22:26:29 Running org.opendaylight.odlparent.featuretest.SingleFeatureTest
08:23:11 Build timed out (after 900 minutes). Marking the build as failed.

Have you seen the build always failed with ofp?

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Anil 
Belur
Sent: Monday, January 29, 2018 4:09 AM
To: Jenkins ; Anil Vishnoi 

Cc: openflowplugin-dev ; Release 

Subject: Re: [openflowplugin-dev] [release] Autorelease nitrogen failed to 
build odl-openflowplugin-southbound from openflowplugin

Hello OF-dev team,

AR Nitrogen is failing on SFT tests for OF. Can we get these issues address 
soon, since we have an Nitrogen SR3 coming release next week.

Thanks,
Anil

Tests in error:
  diag failed; some bundles failed to start
diag: Failure {Active=244, Resolved=5, Waiting=0, Starting=0, Failure=1, 
GracePeriod=2, Unknown=0, Installed=0, Stopping=0}
1. NOK org.opendaylight.openflowplugin.blueprint-config: OSGi state = Active, 
Karaf bundleState = GracePeriod, due to: Blueprint
1/27/18 4:29 PM
Missing dependencies:
(objectClass=org.opendaylight.openflowjava.protocol.spi.connection.SwitchConnectionProvider)
 Initial app config OpenflowProviderConfig 
(objectClass=org.opendaylight.openflowjava.protocol.spi.connection.SwitchConnectionProvider)

2. NOK org.opendaylight.openflowplugin.extension-onf: OSGi state = Active, 
Karaf bundleState = Failure, due to: Blueprint
1/27/18 4:32 PM
Exception:
null
java.util.concurrent.TimeoutException
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371)
at 
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Missing dependencies:
(objectClass=org.opendaylight.openflowplugin.extension.api.OpenFlowPluginExtensionRegistratorProvider)
 
(objectClass=org.opendaylight.openflowjava.protocol.spi.connection.SwitchConnectionProvider)

3. NOK org.opendaylight.openflowplugin.openflowjava.blueprint-config: OSGi 
state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
1/27/18 4:29 PM
Missing dependencies:
(&(|(type=default)(!(type=*)))(objectClass=org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer))
 
(&(|(type=default)(!(type=*)))(objectClass=org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer))

On Sun, Jan 28, 2018 at 2:33 AM, Jenkins 
> 
wrote:
Attention openflowplugin-devs,

Autorelease nitrogen failed to build odl-openflowplugin-southbound from 
openflowplugin in build
373. Attached is a snippet of the error message related to the
failure that we were able to automatically parse as well as console logs.


Console Logs:
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/autorelease-release-nitrogen/373

Jenkins Build:
https://jenkins.opendaylight.org/releng/job/autorelease-release-nitrogen/373/

Please review and provide an ETA on when a fix will be available.

Thanks,
ODL releng/autorelease team


___
release mailing list
rele...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/release

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] is dhcp issue fixed on carbon?

[D Arunprakash]

Hi Jamo,
All the TCs are failed, please check.

Seems to be basic issue,

===
Message:Parent suite setup failed:
No keyword with name 
'KarafKeywords.Execute_Controller_Karaf_Command_On_Background log:set TRACE 
org.opendaylight.openflowplugin.impl' found.
===

Regards,
Arun

-Original Message-
From: Jamo Luhrsen [mailto:jluhr...@gmail.com] 
Sent: Thursday, January 25, 2018 11:21 AM
To: D Arunprakash <d.arunprak...@ericsson.com>; Sam Hague <sha...@redhat.com>
Cc: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; Manu B 
<man...@ericsson.com>; Jamo Luhrsen <jluhr...@redhat.com>
Subject: Re: [openflowplugin-dev] is dhcp issue fixed on carbon?

I didn't add any extra tcpdump yet, but here is a job that will enable TRACE 
for ofp.impl.

it's only running the four connectivity/ folder suites.

https://jenkins.opendaylight.org/sandbox/job/netvirt-csit-1node-openstack-ocata-jamo-upstream-stateful-carbon/11/

JamO


On 1/24/18 8:04 PM, D Arunprakash wrote:
> Please enable the logs for the below package,
> 
> org.opendaylight.openflowplugin.impl
> 
> Regards,
> 
> Arun
> 
> *From:*Sam Hague [mailto:sha...@redhat.com]
> *Sent:* Thursday, January 25, 2018 9:32 AM
> *To:* D Arunprakash <d.arunprak...@ericsson.com>
> *Cc:* Anil Vishnoi <vishnoia...@gmail.com>; openflowplugin-dev 
> <openflowplugin-dev@lists.opendaylight.org>; Vishal Thapar 
> <vishal.tha...@ericsson.com>; Faseela K <faseel...@ericsson.com>; Josh 
> Hershberg <jhers...@redhat.com>; Jamo Luhrsen <jluhr...@redhat.com>; 
> Manu B <man...@ericsson.com>
> *Subject:* RE: is dhcp issue fixed on carbon?
> 
> What logs to enable? Or just the whole openflowplugin, which is very noisy.
> 
> Is packet capture on port 6653 good?
> 
> On Jan 24, 2018 10:54 PM, "D Arunprakash" <d.arunprak...@ericsson.com 
> <mailto:d.arunprak...@ericsson.com>> wrote:
> 
> Hi Sam,
> 
> We need to enable Openflowplugin logs and do packet capture for the
> time window when the tunnel port is delete and added back.
> 
> Regards,
> 
> Arun
> 
> *From:*Anil Vishnoi [mailto:vishnoia...@gmail.com
> <mailto:vishnoia...@gmail.com>]
> *Sent:* Thursday, January 25, 2018 1:17 AM
> *To:* Sam Hague <sha...@redhat.com <mailto:sha...@redhat.com>>
> *Cc:* D Arunprakash <d.arunprak...@ericsson.com
> <mailto:d.arunprak...@ericsson.com>>; openflowplugin-dev
> <openflowplugin-dev@lists.opendaylight.org
> <mailto:openflowplugin-dev@lists.opendaylight.org>>; Vishal Thapar
> <vishal.tha...@ericsson.com <mailto:vishal.tha...@ericsson.com>>;
> Faseela K <faseel...@ericsson.com <mailto:faseel...@ericsson.com>>;
> Josh Hershberg <jhers...@redhat.com <mailto:jhers...@redhat.com>>;
> Jamo Luhrsen <jluhr...@redhat.com <mailto:jluhr...@redhat.com>>;
> Manu B <man...@ericsson.com <mailto:man...@ericsson.com>>
> 
> 
> *Subject:* Re: is dhcp issue fixed on carbon?
> 
> Hi Sam,
> 
> Looks like Arun is looking at it ?
> 
> Arun, if you are not looking at it currently, please let me know I
> will take a look at it.
> 
> Thanks
> 
> Anil
> 
> On Wed, Jan 24, 2018 at 4:25 AM, Sam Hague <sha...@redhat.com
> <mailto:sha...@redhat.com>> wrote:
> 
> Adding openflow to thread.
> 
> Anil, could someone take a look at this for carbon? We are
> seeing a connection flapping and end up missing port status
> updates. This leads to stale models and flows.
> 
> This is blocking the carbon sr3.
> 
> On Jan 24, 2018 12:58 AM, "D Arunprakash"
> <d.arunprak...@ericsson.com <mailto:d.arunprak...@ericsson.com>>
> wrote:
> 
> Ignore my previous email.
> 
> The tunnel port got deleted around 18:49:29.373 and added
> back on 18:52:46.26
> 
> 2018-01-23T18:49:29.373Z|01979|vconn|DBG|tcp:10.30.170.63:6653
> <http://10.30.170.63:6653>: sent (Success): OFPT_PORT_STATUS
> (OF1.3) (xid=0x0): DEL: 4(tun55fb50d0a2b):
> addr:3e:0c:ed:2e:a9:ba
> 
> 2018-01-23T18:52:46.261Z|03083|vconn|DBG|tcp:10.30.170.63:6653
> <http://10.30.170.63:6653>: sent (Success): OFPT_PORT_STATUS
> (OF1.3) (xid=0x0): ADD: 9(tun55fb50d0a2b):
> addr:8a:2f:9f:c6:fe:d9
> 
> Immediately after tunnel delete, I’m seeing so multiple
> switch flaps for quite sometime,
> 
> 2018-01-

Re: [openflowplugin-dev] is dhcp issue fixed on carbon?

[D Arunprakash]

@Vishal Thapar<mailto:vishal.tha...@ericsson.com>, yes the entry will be 
removed from oper Ds, but even after multiple switch disconnects, the port 
remains in inventory, so wanted to know what is happening by enabling logs.

Regards,
ARun

From: Vishal Thapar
Sent: Thursday, January 25, 2018 10:26 AM
To: D Arunprakash <d.arunprak...@ericsson.com>; Sam Hague <sha...@redhat.com>
Cc: Anil Vishnoi <vishnoia...@gmail.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>; Faseela K 
<faseel...@ericsson.com>; Josh Hershberg <jhers...@redhat.com>; Jamo Luhrsen 
<jluhr...@redhat.com>; Manu B <man...@ericsson.com>
Subject: RE: is dhcp issue fixed on carbon?

BTW, you can ignore that flow exception, it is adding flow to a node that is 
not there, probably coz of disconnect.

What does OFP do when a node disconnects? Does it remove its entry from 
operational DS?

Regards,
Vishal.

From: D Arunprakash
Sent: 25 January 2018 09:35
To: Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>
Cc: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Vishal Thapar <vishal.tha...@ericsson.com<mailto:vishal.tha...@ericsson.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Josh 
Hershberg <jhers...@redhat.com<mailto:jhers...@redhat.com>>; Jamo Luhrsen 
<jluhr...@redhat.com<mailto:jluhr...@redhat.com>>; Manu B 
<man...@ericsson.com<mailto:man...@ericsson.com>>
Subject: RE: is dhcp issue fixed on carbon?

Please enable the logs for the below package,

org.opendaylight.openflowplugin.impl


Regards,
Arun
From: Sam Hague [mailto:sha...@redhat.com]
Sent: Thursday, January 25, 2018 9:32 AM
To: D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>
Cc: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Vishal Thapar <vishal.tha...@ericsson.com<mailto:vishal.tha...@ericsson.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Josh 
Hershberg <jhers...@redhat.com<mailto:jhers...@redhat.com>>; Jamo Luhrsen 
<jluhr...@redhat.com<mailto:jluhr...@redhat.com>>; Manu B 
<man...@ericsson.com<mailto:man...@ericsson.com>>
Subject: RE: is dhcp issue fixed on carbon?

What logs to enable? Or just the whole openflowplugin, which is very noisy.

Is packet capture on port 6653 good?

On Jan 24, 2018 10:54 PM, "D Arunprakash" 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>> wrote:
Hi Sam,
We need to enable Openflowplugin logs and do packet capture for the time window 
when the tunnel port is delete and added back.

Regards,
Arun

From: Anil Vishnoi [mailto:vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>]
Sent: Thursday, January 25, 2018 1:17 AM
To: Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>
Cc: D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Vishal Thapar <vishal.tha...@ericsson.com<mailto:vishal.tha...@ericsson.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Josh 
Hershberg <jhers...@redhat.com<mailto:jhers...@redhat.com>>; Jamo Luhrsen 
<jluhr...@redhat.com<mailto:jluhr...@redhat.com>>; Manu B 
<man...@ericsson.com<mailto:man...@ericsson.com>>

Subject: Re: is dhcp issue fixed on carbon?

Hi Sam,

Looks like Arun is looking at it ?

Arun, if you are not looking at it currently, please let me know I will take a 
look at it.

Thanks
Anil

On Wed, Jan 24, 2018 at 4:25 AM, Sam Hague 
<sha...@redhat.com<mailto:sha...@redhat.com>> wrote:
Adding openflow to thread.

Anil, could someone take a look at this for carbon? We are seeing a connection 
flapping and end up missing port status updates. This leads to stale models and 
flows.

This is blocking the carbon sr3.

On Jan 24, 2018 12:58 AM, "D Arunprakash" 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>> wrote:
Ignore my previous email.

The tunnel port got deleted around 18:49:29.373 and added back on 18:52:46.26

2018-01-23T18:49:29.373Z|01979|vconn|DBG|tcp:10.30.170.63:6653<http://10.30.170.63:6653>:
 sent (Success): OFPT_PORT_STATUS (OF1.3) (xid=0x0): DEL: 4(tun55fb50d0a2b): 
addr:3e:0c:ed:2e:a9:ba

2018-01-23T18:52:46.261Z|03083|vconn|DBG|tcp:10.30.170.63:6653<http://10.30.170.63:6653>:
 sent (Success): OFPT_PORT_STATU

Re: [openflowplugin-dev] is dhcp issue fixed on carbon?

[D Arunprakash]

Please enable the logs for the below package,

org.opendaylight.openflowplugin.impl


Regards,
Arun
From: Sam Hague [mailto:sha...@redhat.com]
Sent: Thursday, January 25, 2018 9:32 AM
To: D Arunprakash <d.arunprak...@ericsson.com>
Cc: Anil Vishnoi <vishnoia...@gmail.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>; Vishal Thapar 
<vishal.tha...@ericsson.com>; Faseela K <faseel...@ericsson.com>; Josh 
Hershberg <jhers...@redhat.com>; Jamo Luhrsen <jluhr...@redhat.com>; Manu B 
<man...@ericsson.com>
Subject: RE: is dhcp issue fixed on carbon?

What logs to enable? Or just the whole openflowplugin, which is very noisy.

Is packet capture on port 6653 good?

On Jan 24, 2018 10:54 PM, "D Arunprakash" 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>> wrote:
Hi Sam,
We need to enable Openflowplugin logs and do packet capture for the time window 
when the tunnel port is delete and added back.

Regards,
Arun

From: Anil Vishnoi [mailto:vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>]
Sent: Thursday, January 25, 2018 1:17 AM
To: Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>
Cc: D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Vishal Thapar <vishal.tha...@ericsson.com<mailto:vishal.tha...@ericsson.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Josh 
Hershberg <jhers...@redhat.com<mailto:jhers...@redhat.com>>; Jamo Luhrsen 
<jluhr...@redhat.com<mailto:jluhr...@redhat.com>>; Manu B 
<man...@ericsson.com<mailto:man...@ericsson.com>>

Subject: Re: is dhcp issue fixed on carbon?

Hi Sam,

Looks like Arun is looking at it ?

Arun, if you are not looking at it currently, please let me know I will take a 
look at it.

Thanks
Anil

On Wed, Jan 24, 2018 at 4:25 AM, Sam Hague 
<sha...@redhat.com<mailto:sha...@redhat.com>> wrote:
Adding openflow to thread.

Anil, could someone take a look at this for carbon? We are seeing a connection 
flapping and end up missing port status updates. This leads to stale models and 
flows.

This is blocking the carbon sr3.

On Jan 24, 2018 12:58 AM, "D Arunprakash" 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>> wrote:
Ignore my previous email.

The tunnel port got deleted around 18:49:29.373 and added back on 18:52:46.26

2018-01-23T18:49:29.373Z|01979|vconn|DBG|tcp:10.30.170.63:6653<http://10.30.170.63:6653>:
 sent (Success): OFPT_PORT_STATUS (OF1.3) (xid=0x0): DEL: 4(tun55fb50d0a2b): 
addr:3e:0c:ed:2e:a9:ba

2018-01-23T18:52:46.261Z|03083|vconn|DBG|tcp:10.30.170.63:6653<http://10.30.170.63:6653>:
 sent (Success): OFPT_PORT_STATUS (OF1.3) (xid=0x0): ADD: 9(tun55fb50d0a2b): 
addr:8a:2f:9f:c6:fe:d9

Immediately after tunnel delete, I’m seeing so multiple switch flaps for quite 
sometime,

2018-01-23T18:49:35.155Z|02108|rconn|DBG|br-int<->unix: entering ACTIVE
2018-01-23T18:49:35.155Z|02109|vconn|DBG|unix: sent (Success): OFPT_HELLO 
(OF1.3) (xid=0x75):
version bitmap: 0x04
2018-01-23T18:49:35.155Z|02110|vconn|DBG|unix: received: OFPT_HELLO (OF1.3) 
(xid=0x1):

2018-01-23T18:49:35.307Z|02144|rconn|DBG|br-int<->unix: connection closed by 
peer
2018-01-23T18:49:35.307Z|02145|rconn|DBG|br-int<->unix: entering DISCONNECTED
2018-01-23T18:49:35.324Z|02146|rconn|DBG|br-int<->unix: entering ACTIVE

Also, I’m seeing error in karaf log

2018-01-23 18:49:29,378 | WARN  | entLoopGroup-7-3 | DeviceContextImpl  
  | 280 - org.opendaylight.openflowplugin.impl - 0.4.3.SNAPSHOT | 
writePortStatusMessage
2018-01-23 18:49:29,379 | WARN  | entLoopGroup-7-3 | DeviceContextImpl  
  | 280 - org.opendaylight.openflowplugin.impl - 0.4.3.SNAPSHOT | submit 
transaction for write port status message
2018-01-23 18:49:29,379 | WARN  | rd-dispatcher-23 | ShardDataTree  
  | 184 - 
org.opendaylight.controller.sa<http://org.opendaylight.controller.sa>l-distributed-datastore
 - 1.5.3.SNAPSHOT | member-1-shard-inventory-operational: Store Tx 
member-1-datastore-operational-fe-0-chn-8-txn-11-0: Data validation failed for 
path 
/(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:246869078989547}]/AugmentationIdentifier{childNames=[(urn:opendaylight:flow:inventory?revision=2013-08-19)port-number,
 (urn:opendaylight:flow:inventory?revision=2013-08-19)stale-group, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)supported-match-types, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)table, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)group, 
(urn:opendaylight:flow:inventory?revision=2013-08-19)manufacturer, 
(urn:open

Re: [openflowplugin-dev] [opendaylight-dev] [release] odlparent + yangtools bump

[D Arunprakash]

Hi Luis,
We haven’t started anything on this, let me check with Vishal and comeback on 
this.

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Luis 
Gomez
Sent: Thursday, January 18, 2018 12:45 AM
To: Vishal Thapar ; openflowplugin-dev 

Subject: Re: [openflowplugin-dev] [opendaylight-dev] [release] odlparent + 
yangtools bump

Is anyone looking at this? this is currently blocking netvirt and other 
projects relying in ofp.

BR/Luis

On Jan 16, 2018, at 7:43 PM, Vishal Thapar 
> wrote:

Hi Luis,

There is already a Jira [4], and patch [5] from Robert in works. OFPlugin could 
do a similar workaround to one I did for OVSDB while waiting for Robert’s patch 
to land.

Regards,
Vishal.

[4] https://jira.opendaylight.org/browse/NETCONF-496
[5] https://git.opendaylight.org/gerrit/67212

From: 
openflowplugin-dev-boun...@lists.opendaylight.org
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Luis 
Gomez
Sent: 17 January 2018 08:58
To: openflowplugin-dev 
>
Subject: [openflowplugin-dev] Fwd: [opendaylight-dev] [release] odlparent + 
yangtools bump

FYI the topology issue described by Vishal below also happens in 
openflowplugin, so the proposed workarounds should also work here. Should we 
open a ticket for this?

BR/Luis



Begin forwarded message:

From: Vishal Thapar 
>
Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump
Date: January 16, 2018 at 6:08:46 AM PST
To: Tom Pantelis >
Cc: Stephen Kitt >, odl-dev-list 
>, 
"yangtools-...@lists.opendaylight.org"
 
>,
 Release >

Hi Tom,

Yeah, this is another workaround. In case of OVSDB I know which version I want 
to use. But it is still not a proper fix. Something like restconf/apidocs can’t 
know the correct version. If latest is correct one, should probably move older 
ones to differently named bundles.

Regards,
Vishal.

From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: 16 January 2018 19:13
To: Vishal Thapar 
>
Cc: Robert Varga >; Stephen Kitt 
>; odl-dev-list 
>; Release 
>; 
yangtools-...@lists.opendaylight.org
Subject: Re: [release] [opendaylight-dev] odlparent + yangtools bump



On Tue, Jan 16, 2018 at 1:57 AM, Vishal Thapar 
> wrote:
Thanks for the lead Tom.

I’m not subscribed to yangtools-dev so they may not get this mail.

I followed it to new yangtools unable to figure out which version to pick when 
2 versions of same model are loaded. Network-topology happens to be one of 8 
such instances I saw that have two different versions under same yang file and 
both are loaded [1]. I think this is more of an existing bad design or 
oversight being exposed by new yangtools, your opinion may wary.

I was able to workaround part of OVSDB issue by hardcoding the revision when 
deserializing [2]. I am now able to use OVSDB plugin to configure OVS, but 
restconf is still failing as well as odl-mdsal-apidocsc gives 500 error. IMO, 
there are two ways to take care of this:


  1.  Publish and modify all test scripts etc. to specify revision in rest 
calls too [if possible].
  2.  Eliminate duplicate models by moving older models to appropriately named 
folders, something similar to ietf-yang-types [3] only moving older one to use 
the revision in folder name, to avoid changes to all consumers.
  3.  ‘Fix’ in yangtools to pick the newer version.

Note that I mention yangtools but this could likely be an mdsal or restconf 
issue too, am not familiar enough with any of these to make a definitive 
statement on where the ‘bug’ is. Also, without rest allOVSDB/Genius/Netvirt 
CSIT will be broken, even if rest of bump activity goes through smoothly.


This sounds familiar - I ran into it in another project and worked around it: 
https://git.opendaylight.org/gerrit/#/c/66536/2/impl/src/main/java/org/opendaylight/jsonrpc/impl/Util.java
 - the comments in the 

Re: [openflowplugin-dev] Migrating liblldp from controller project to openflowplugin project

[D Arunprakash]

Hi Shuva,
I hope you remember Openflowplugin dev email discussions, attached the email 
for your reference. You have given a go ahead for the same.

Regards,
Arun

From: Shuva Kar [mailto:shuva.jyoti.kar...@gmail.com]
Sent: Thursday, January 11, 2018 3:36 PM
To: D Arunprakash <d.arunprak...@ericsson.com>
Cc: openflowplugin-dev@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; 
thanh...@linuxfoundation.org
Subject: Re: [openflowplugin-dev] Migrating liblldp from controller project to 
openflowplugin project

Thanks Arun for the heads-up. But could you please let me know why this move ? 
Since lldp has nothing to do with Ofp.

-shuva
On 11-Jan-2018, at 3:30 PM, D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>> wrote:

Hello,
We are in the process of migrating liblldp from controller project to 
Openflowplugin project.

The following sequence will be followed as part of this migration,


  1.  Add liblldp module to openflowplugin project 
(https://git.opendaylight.org/gerrit/#/c/67051/ )
  2.  Migrate gerrit history from controller/opendaylight/commons/liblldp to 
openflowplugin/libraries/liblldp
  3.  Modify packaging structure of liblldp in Openflowplugin (like change 
package structure from controller to Openflowplugin, etc.,) and make 
Openflowplugin modules point to ofp liblldp.
  4.  Modify genius, netvirt to point to ofp liblldp.
  5.  Remove liblldp from controller project.

Please let us know if you see any issues with the above-mentioned approach.

Regards,
Arun
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

--- Begin Message ---
All other things being equal, I'd like to see the groupId change, but probably 
not the artifactId.

--Colin

On Thu, Jul 27, 2017 at 4:30 AM Vishal Thapar 
<vishal.tha...@ericsson.com<mailto:vishal.tha...@ericsson.com>> wrote:


   Hi OFP devs,



   As a consumer of both OFP and liblldp I had a question, would projectId of 
liblldp be changed as part of this activity? Note that am fine with either 
approach, but wanted to know as such a change would require us to be prepared.



   Regards,

   Vishal.



   From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>]
 On Behalf Of Jozef Bacigál
   Sent: 27 July 2017 13:56
   To: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>; 
Shuva Kar <shuva.jyoti.kar...@gmail.com<mailto:shuva.jyoti.kar...@gmail.com>>
   Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
   Subject: Re: [openflowplugin-dev] Fwd: [Project-proposals] liblldp project 
proposal



   No objections.

 _

   Od: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>
   Odoslané: štvrtok, 27. júla 2017 5:48:37
   Komu: Shuva Kar
   Kópia: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
   Predmet: Re: [openflowplugin-dev] Fwd: [Project-proposals] liblldp project 
proposal



+1 (just for record)



   On Wed, Jul 26, 2017 at 8:41 PM, Shuva Kar 
<shuva.jyoti.kar...@gmail.com<mailto:shuva.jyoti.kar...@gmail.com>> wrote:

  Please go ahead




  Br,shuva



  On Thu, Jul 27, 2017 at 9:09 AM, Abhijit Kumbhare 
<abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>> wrote:

 Hi OpenFlow Plugin committers,



 Do you have any objections to putting the LLDP code currently in the 
controller project into OpenFlow Plugin. Anil and I have voiced opinion that it 
is OK to add it to OpenFlow Plugin. If no valid objection comes up till Monday 
- we can consider it as a go ahead.



 Abhijit



 -- Forwarded message --
 From: Colin Dixon <co...@colindixon.com<mailto:co...@colindixon.com>>
 Date: Wed, Jul 26, 2017 at 6:02 PM
 Subject: Re: [Project-proposals] liblldp project proposal
 To: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>
 Cc: Abhijit Kumbhare 
<abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>>, Sam Hague 
<sha...@redhat.com<mailto:sha...@redhat.com>>, 
"project-propos...@lists.opendaylight.org<mailto:project-propos...@lists.opendaylight.org>"
 
<project-propos...@lists.opendaylight.org<mailto:project-propos...@lists.opendaylight.org>>



 It just seems easier to me to put the code in OpenFlow plugin than to 
pull a new project out of a hat that somehow doesn't b

[openflowplugin-dev] Migrating liblldp from controller project to openflowplugin project

[D Arunprakash]

Hello,
We are in the process of migrating liblldp from controller project to 
Openflowplugin project.

The following sequence will be followed as part of this migration,


  1.  Add liblldp module to openflowplugin project ( 
https://git.opendaylight.org/gerrit/#/c/67051/ )
  2.  Migrate gerrit history from controller/opendaylight/commons/liblldp to 
openflowplugin/libraries/liblldp
  3.  Modify packaging structure of liblldp in Openflowplugin (like change 
package structure from controller to Openflowplugin, etc.,) and make 
Openflowplugin modules point to ofp liblldp.
  4.  Modify genius, netvirt to point to ofp liblldp.
  5.  Remove liblldp from controller project.

Please let us know if you see any issues with the above-mentioned approach.

Regards,
Arun
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Won’t be able to join tomorrow’s OFP meeting

[D Arunprakash]

Hi Anil,
Nothing major to discuss this week from our side, we can meet next Tuesday.

Also, we are unable to add you as a reviewer, the following error message is 
thrown, please check it.

==
Anil Vishnoi <vishnoia...@gmail.com> does not identify a registered user or 
group
==

Please review the following patches whenever you have time.
https://git.opendaylight.org/gerrit/#/c/66694/

Regards,
Arun

-Original Message-
From: Anil Vishnoi [mailto:vishnoia...@gmail.com] 
Sent: Tuesday, January 02, 2018 2:55 AM
To: D Arunprakash <d.arunprak...@ericsson.com>; Hema Gopalkrishnan 
<hema.gopalkrish...@ericsson.com>; Abhijit Kumbhare <abhijitk...@gmail.com>; 
Sunil Kumar G <sunil.g.ku...@ericsson.com>; Shuva Jyoti kar 
<shuva.jyoti@ericsson.com>; ece...@gmail.com
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: Won’t be able to join tomorrow’s OFP meeting


Hi Folks,

I am on PTO tomorrow and also traveling as well, so won’t be able to run 
tomorrow’s OFP meeting. If you want to meet to discuss any agenda please feel 
free to meet tomorrow otherwise we can cancel tomorrow’s meeting and meet next 
Tuesday. Please let me know if there is anything urgent that you want me to 
have a look, i will get some bandwidth tomorrow evening so i can take a look at 
those.

iPhone.iTypos.iApologize
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [release] [OpenDaylight TSC] New OpenFlow Plugin PTL

[D Arunprakash]

Thanks Abhijit for your help and support till now.

Congratulations Anil !! ☺

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Hema 
Gopalkrishnan
Sent: Sunday, December 10, 2017 12:42 PM
To: Muthukumaran K ; Vishal Thapar 
; Faseela K ; daya kamath 
; George Zhao ; Shuva Kar 

Cc: t...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Release 
Subject: Re: [openflowplugin-dev] [release] [OpenDaylight TSC] New OpenFlow 
Plugin PTL

Thanks Abhijit for being OFPlugin PTL for so long !

Congratulations Anil !

Regards,
Hema

From: 
openflowplugin-dev-boun...@lists.opendaylight.org
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: 10 December 2017 12:29
To: Vishal Thapar 
>; Faseela K 
>; daya kamath 
>; George Zhao 
>; Shuva Kar 
>
Cc: t...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org;
 Release >
Subject: Re: [openflowplugin-dev] [release] [OpenDaylight TSC] New OpenFlow 
Plugin PTL

Thanks Abhijit for leading OFPlugin for a long time

Hearty congratulations Anil !!

Regards
Muthu


From: 
openflowplugin-dev-boun...@lists.opendaylight.org
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Vishal 
Thapar
Sent: Sunday, December 10, 2017 11:34 AM
To: Faseela K; daya kamath; George Zhao; Shuva Kar
Cc: t...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org;
 Release
Subject: Re: [openflowplugin-dev] [release] [OpenDaylight TSC] New OpenFlow 
Plugin PTL

Thanks Abhijit for all your support these years.

Congratulations Anil. Though it is a bit bittersweet to lose you as PTL for 
OVSDB.

Regards,
Vishal.

From: 
release-boun...@lists.opendaylight.org
 [mailto:release-boun...@lists.opendaylight.org] On Behalf Of Faseela K
Sent: 10 December 2017 11:23
To: daya kamath >; George Zhao 
>; Shuva Kar 
>
Cc: t...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org;
 Release >
Subject: Re: [release] [openflowplugin-dev] [OpenDaylight TSC] New OpenFlow 
Plugin PTL

Congrats Anil!
And thanks Abhijit for all your support!

Thanks,
Faseela

From: 
openflowplugin-dev-boun...@lists.opendaylight.org
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of daya 
kamath
Sent: Sunday, December 10, 2017 11:19 AM
To: George Zhao >; 
Shuva Kar >
Cc: t...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org;
 Release >
Subject: Re: [openflowplugin-dev] [release] [OpenDaylight TSC] New OpenFlow 
Plugin PTL

+1 for george's comment. thanks abhijit, and congratulations anil!


On Sunday, December 10, 2017, 10:33:34 AM GMT+5:30, Shuva Kar 
> wrote:


Congrats Anil :)
On 10-Dec-2017, at 7:35 AM, George Zhao 
> wrote:

Thank you Abhijit for your working on openflow project, one of the most 
dependent project in ODL.

Congratulations,  Anil.

George


From: 
tsc-boun...@lists.opendaylight.org 
[mailto:tsc-boun...@lists.opendaylight.org] On Behalf Of Abhijit Kumbhare
Sent: Saturday, December 09, 2017 4:16 PM
To: Anil Vishnoi >; Release 
>
Cc: 

Re: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin

[D Arunprakash]

Hi Muthu/Faseela,
The datastore service is registered from genius md-sal, if we install only 
Openflowplugin features then we will have problem to obtain datastore service 
status.

For now, it's not possible to check datastore service from Openflowplugin using 
snd framework.

We can open the southbound interface based on the system-ready from infrautils.

Regards,
Arun
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: Thursday, November 23, 2017 11:19 AM
To: Faseela K ; 
openflowplugin-dev@lists.opendaylight.org
Cc: infrautils-...@lists.opendaylight.org; Dayavanti Gopal Kamath 
; Tom Pantelis 
Subject: Re: [openflowplugin-dev] Proposing infrautils.ready integration for 
openflowplugin

Yes. That would be the right approach and can simplify the check by OFPlugin 
easier


Regards
Muthu


From: Faseela K
Sent: Thursday, November 23, 2017 11:17 AM
To: Muthukumaran K; 
openflowplugin-dev@lists.opendaylight.org
Cc: 
infrautils-...@lists.opendaylight.org;
 Sam Hague; Dayavanti Gopal Kamath; Vivek Srivastava V; Tom Pantelis
Subject: RE: Proposing infrautils.ready integration for openflowplugin

Thanks for the input Muthu!
Diagstatus is already integrated to openflowplugin, and hence an additional 
check can be made to see whether DATASTORE service is operational when system 
is "ready", before opening up the southbound interfaces.

Thanks,
Faseela

From: Muthukumaran K
Sent: Thursday, November 23, 2017 11:15 AM
To: Faseela K >; 
openflowplugin-dev@lists.opendaylight.org
Cc: 
infrautils-...@lists.opendaylight.org;
 Sam Hague >; Dayavanti Gopal 
Kamath 
>;
 Vivek Srivastava V 
>
Subject: RE: Proposing infrautils.ready integration for openflowplugin

It would be cleaner to include the datastore check apart from just ready state.

When the application-features get installed, corresponding yang models are 
absorbed to build schema context incrementally. There is no absolute telling 
when this completes depending upon how quick application features get installed 
(Which in turn depend upon their dependency graph(s)). The schemacontext 
present at the time of restoration will be used as it is for validating and 
restoring data during scenarios like reboot.

Though most of the apps get installed as part of boot features, it would be 
better to include this exclusive check in addition to standard ready check

Hope we are all in sync

Regards
Muthu


From: Faseela K
Sent: Tuesday, November 21, 2017 10:46 PM
To: 
openflowplugin-dev@lists.opendaylight.org
Cc: 
infrautils-...@lists.opendaylight.org;
 Sam Hague; Dayavanti Gopal Kamath; Vivek Srivastava V; Muthukumaran K
Subject: Proposing infrautils.ready integration for openflowplugin

Hi Shuva/Arun
  As a follow up to diagstatus integration to openflowplugin, I would like to 
propose the integration of infrautils.ready for openflowplugin.
   This way openflowplugin can open the southbound ports after all bundles have 
come up properly.
   Also diagstatus can fetch the dynamic service status based on the current 
southbound connection status as well as other criteria.
   This will help in many cases, including initial system bring up as well as 
cluster reboot, as there is enough time for all applications to come up 
gracefully before they start receiving southbound events.
   Please let us know your thoughts on the same.
Thanks,
Faseela
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin

[D Arunprakash]

What will happen if we install features manually with some time delay between 
each others?
Like install Openflowplugin feature and give some time delay and then install 
the next features (may be an application)?

Will the notification be received twice?

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: Thursday, November 23, 2017 11:19 AM
To: Faseela K ; 
openflowplugin-dev@lists.opendaylight.org
Cc: infrautils-...@lists.opendaylight.org; Dayavanti Gopal Kamath 
; Tom Pantelis 
Subject: Re: [openflowplugin-dev] Proposing infrautils.ready integration for 
openflowplugin

Yes. That would be the right approach and can simplify the check by OFPlugin 
easier


Regards
Muthu


From: Faseela K
Sent: Thursday, November 23, 2017 11:17 AM
To: Muthukumaran K; 
openflowplugin-dev@lists.opendaylight.org
Cc: 
infrautils-...@lists.opendaylight.org;
 Sam Hague; Dayavanti Gopal Kamath; Vivek Srivastava V; Tom Pantelis
Subject: RE: Proposing infrautils.ready integration for openflowplugin

Thanks for the input Muthu!
Diagstatus is already integrated to openflowplugin, and hence an additional 
check can be made to see whether DATASTORE service is operational when system 
is "ready", before opening up the southbound interfaces.

Thanks,
Faseela

From: Muthukumaran K
Sent: Thursday, November 23, 2017 11:15 AM
To: Faseela K >; 
openflowplugin-dev@lists.opendaylight.org
Cc: 
infrautils-...@lists.opendaylight.org;
 Sam Hague >; Dayavanti Gopal 
Kamath 
>;
 Vivek Srivastava V 
>
Subject: RE: Proposing infrautils.ready integration for openflowplugin

It would be cleaner to include the datastore check apart from just ready state.

When the application-features get installed, corresponding yang models are 
absorbed to build schema context incrementally. There is no absolute telling 
when this completes depending upon how quick application features get installed 
(Which in turn depend upon their dependency graph(s)). The schemacontext 
present at the time of restoration will be used as it is for validating and 
restoring data during scenarios like reboot.

Though most of the apps get installed as part of boot features, it would be 
better to include this exclusive check in addition to standard ready check

Hope we are all in sync

Regards
Muthu


From: Faseela K
Sent: Tuesday, November 21, 2017 10:46 PM
To: 
openflowplugin-dev@lists.opendaylight.org
Cc: 
infrautils-...@lists.opendaylight.org;
 Sam Hague; Dayavanti Gopal Kamath; Vivek Srivastava V; Muthukumaran K
Subject: Proposing infrautils.ready integration for openflowplugin

Hi Shuva/Arun
  As a follow up to diagstatus integration to openflowplugin, I would like to 
propose the integration of infrautils.ready for openflowplugin.
   This way openflowplugin can open the southbound ports after all bundles have 
come up properly.
   Also diagstatus can fetch the dynamic service status based on the current 
southbound connection status as well as other criteria.
   This will help in many cases, including initial system bring up as well as 
cluster reboot, as there is enough time for all applications to come up 
gracefully before they start receiving southbound events.
   Please let us know your thoughts on the same.
Thanks,
Faseela
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

[openflowplugin-dev] Spec review for OFPGC_ADD_OR_MOD support in Openflowplugin

[D Arunprakash]

Hi,
I have raised the spec for OFPGC_ADD_OR_MOD support in Openflowplugin for 
OVS2.6 and above. Please review it and provide your comments on the same.

https://git.opendaylight.org/gerrit/#/c/65465/

Regards,
Arun
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] openflowplugin master build error

[D Arunprakash]

Hi Faseela,
There is a check-style error in your review, could you please fix and try again?

18:55:10 [WARN] 
/w/workspace/openflowplugin-verify-oxygen-mvn33-openjdk8/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/statusanddiag/OpenflowPluginStatusMonitor.java:11:
 'org.opendaylight.infrautils.diagstatus.DiagStatusService' should be separated 
from previous import group by one line. [CustomImportOrder]

I guess it is showing all the existing errors as well.

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela 
K
Sent: Saturday, October 14, 2017 11:15 PM
To: openflowplugin-dev@lists.opendaylight.org
Subject: [openflowplugin-dev] openflowplugin master build error

Hello openflowplugin-devs,

I am getting some javadocs error at openflowplugin-impl for one of my patches.

https://jenkins.opendaylight.org/releng/job/openflowplugin-verify-oxygen-mvn33-openjdk8/324/console

Is anyone else hitting similar issues?

18:55:42 [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (attach-javadocs) on 
project openflowplugin-impl: MavenReportException: Error while generating 
Javadoc:
18:55:42 [ERROR] Exit code: 1 - 
/w/workspace/openflowplugin-verify-oxygen-mvn33-openjdk8/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/connection/listener/OpenflowProtocolListenerInitialImpl.java:125:
 warning: no @return
18:55:42 [ERROR] protected boolean checkState(final 
ConnectionContext.CONNECTION_STATE expectedState) {
18:55:42 [ERROR] ^
18:55:42 [ERROR] 
/w/workspace/openflowplugin-verify-oxygen-mvn33-openjdk8/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/datastore/multipart/AbstractMultipartWriter.java:40:
 warning: no @param for withParents
18:55:42 [ERROR] protected  void writeToTransaction(final 
InstanceIdentifier path,
18:55:42 [ERROR] ^
18:55:42 [ERROR] 
/w/workspace/openflowplugin-verify-oxygen-mvn33-openjdk8/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/device/initialization/AbstractDeviceInitializer.java:40:
 warning: no @return
18:55:42 [ERROR] public Future initialize(@Nonnull final DeviceContext 
deviceContext,


Thanks,
Faseela
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] hitless resync

[D Arunprakash]

To add:
Bundle based reconciliation is added via the below patch and this mechanism is 
NOT enabled by default. This is an alternate to FRM reconciliation, if you 
enable bundle based reconciliation, then instead of default reconciliation 
bundle based will be used.
https://git.opendaylight.org/gerrit/#/c/60520/

Bundles are supported from OVS 2.6 and above.

Bundles are added as an extension in OFPlugin, using bundles application can 
send flow/group via bundles extension.
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Bundles_extension_support

Usage:
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Bundles_usage

There are no CSIT available as of now, but there is a plan to add it soon.

Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Abhijit 
Kumbhare
Sent: Friday, October 13, 2017 9:21 AM
To: Anil Vishnoi 
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] hitless resync

First of all - yes - CSIT needs to be added for the hitless resync. Secondly 
hitless resync is different from bundles. Hitless resync is a reconciliation 
mechanism which uses bundles in order to be - errr hitless. The basic idea is 
that the switch will continue using the original flow table/s, the controller 
replays the flows/groups from the config into a bundle, the switch receives the 
bundle in a copy of flow table/s - and once the bundle programming is done 
makes the copy active. Basically to avoid datapath disruption during 
reconciliation.

The bundles feature as present is available from OVS 2.6 and above.

Gobinath has added a reconciliation framework which would allow to plug in a 
different resync mechanism in the patches:

https://git.opendaylight.org/gerrit/#/q/owner:gobinath%2540ericsson.com+status:merged+project:openflowplugin

I don't believe he has actually added the hitless resync (looking at the 
patches) - I will ask him to shed more light.

About:

- How do we verify this feature? is there a way to check bundle programming has 
really happened?

We would need to have tests verifying reconciliation with zero datapath 
disruption - so we will need to think about it a bit.


On Thu, Oct 12, 2017 at 1:15 PM, Anil Vishnoi 
> wrote:


On Thu, Oct 12, 2017 at 10:53 AM, Luis Gomez 
> wrote:
I have few questions on this feature:

- Is this feature enabled by default?
​Yes, its a feature, but as of now no application is basically using it. We do 
have a sample application that shows  how user can use this feature.
https://github.com/opendaylight/openflowplugin/tree/master/samples/sample-bundles
​

- Which OVS version supports bundles? I believe we currently use 2.5.2 in 
latest tools VM
​I believe 2.5.2 don't have support, but i am not sure. ​

- How do we activate bundle programming? is it enough to push a bunch of 
flows/group to FRM using REST?
​I will get back to you on that.
- How do we verify this feature? is there a way to check bundle programming has 
really happened?
​Bundle failure generates the error, but i think the easiest way probably is to 
program different set of flows with bundle and verify that all the flows are 
present in the switch.


BR/Luis


On Oct 12, 2017, at 10:26 AM, Anil Vishnoi 
> wrote:

No, there is no CSIT test for bundles.

On Thu, Oct 12, 2017 at 10:15 AM, Jamo Luhrsen 
> wrote:
it's the thing that uses openflow bundles. I didn't follow the dev cycle
with it, but I get the sense that it works now.

https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Hitless_resync

JamO

On 10/12/2017 10:04 AM, Luis Gomez wrote:
> What is hitless resync in the OF plugin context?
>
>> On Oct 12, 2017, at 8:22 AM, Jamo Luhrsen 
>> > wrote:
>>
>> Hi OFP,
>>
>> We talked a little about this hitless resync feature from openflowplugin. 
>> It's of
>> interest to netvirt. I'm wondering if there are any CSIT jobs that validate 
>> it in
>> the openflowplugin CSIT jobs?
>>
>> We'll be adding some netvirt test cases that will also test it, but just 
>> from a
>> higher level than maybe it would be tested at your level.
>>
>> Thanks,
>> JamO
>
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev



--
Thanks
Anil




--
Thanks
Anil

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] Problem with NoviFlow experimenters in master version current.

[D Arunprakash]

Hi Yann,
You might hit this issue if the registration for experimenters are not done. If 
its vendor specific extension, then you need to register yourself before using 
it.
For example, bundle experimenters are registered in OnfExtensionProvider.java.

switchConnectionProvider.registerExperimenterMessageSerializer(
new ExperimenterIdTypeSerializerKey<>(OFConstants.OFP_VERSION_1_3,
  OnfConstants.ONF_EXPERIMENTER_ID,
  
OnfConstants.ONF_ET_BUNDLE_CONTROL,
 ExperimenterDataOfChoice.class),
new BundleControlFactory());


You should have similar code in previous release which you might have missed to 
port. Could you please check that.
Regards,
Arun

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of yann 
bourdeau
Sent: Tuesday, October 03, 2017 3:49 AM
To: Yrineu Rodrigues 
Cc: openflowplugin-dev@lists.opendaylight.org; Arun Paneri (NoviFlow) 

Subject: Re: [openflowplugin-dev] Problem with NoviFlow experimenters in master 
version current.

Hi Yrineu,

Thanks for taking time to reply. It is not with OVS but NoviFlow 
switches. I already set the version to 1.3 in the switch. Like I said it was 
working the previous release, something must have changed somewhere but I was 
not able to pinpoint it yet.




Le 2 oct. 2017 à 17:05, Yrineu Rodrigues 
> a écrit :

Hi Yann,

Thanks for sharing that issue with us! I faced an issue like that in the past 
when I had tried to configure ODL openflow plugin with my OVS instance. I don't 
know if you are using OVS, but if yes, it may can be solved if you manually set 
OF version as 1.3 on your OVS instance.

I hope that it can help you.

On Mon, Oct 2, 2017 at 5:50 PM, yann bourdeau 
> wrote:
Hi all,

I’m trying to port the NoviFlow to the latest master version of ODL and I have 
run into an issue.

I always got :
2017-10-02 16:01:49,757 | WARN  | entLoopGroup-9-1 | ActionUtil 
  | 320 - org.opendaylight.openflowplugin.impl - 0.6.0.SNAPSHOT | 
Serializer for action interface 
org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.noviflow.action.rev170317.nodes.node.table.flow.instructions.instruction.instruction.apply.actions._case.apply.actions.action.action.NfxActionPopVxlanHeaderNodesNodeTableFlowApplyActionsCase
 for version 4 not found.


From the stack trace:

java.lang.IllegalStateException: Serializer for key: msgVersion: 4 objectType: 
org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.common.action.rev150203.actions.grouping.Action
 action type: 
org.opendaylight.yang.gen.v1.urn.opendaylight.openflowjava.nfx.action.rev170314.action.container.action.choice.ActionPopVxlanHeader
 experimenterID: 4278190082 was not found - please verify that you are using 
correct message combination (e.g. OF v1.0 message to OF v1.0 device)
at 
org.opendaylight.openflowjava.protocol.impl.serialization.SerializerRegistryImpl.getSerializer(SerializerRegistryImpl.java:72)
at 
org.opendaylight.openflowplugin.impl.protocol.serialization.util.ActionUtil.lambda$null$0(ActionUtil.java:57)
at java.util.Optional.map(Optional.java:215)[:1.8.0_121]
at 
org.opendaylight.openflowplugin.impl.protocol.serialization.util.ActionUtil.lambda$writeAction$1(ActionUtil.java:53)
at java.util.Optional.flatMap(Optional.java:241)[:1.8.0_121]
at 
org.opendaylight.openflowplugin.impl.protocol.serialization.util.ActionUtil.writeAction(ActionUtil.java:49)
at 
org.opendaylight.openflowplugin.impl.protocol.serialization.instructions.AbstractActionInstructionSerializer.lambda$null$1(AbstractActionInstructionSerializer.java:45)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)[:1.8.0_121]
at 
java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:352)[:1.8.0_121]
at 
java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)[:1.8.0_121]
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)[:1.8.0_121]
at 
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)[:1.8.0_121]
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)[:1.8.0_121]
at 
java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)[:1.8.0_121]
at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)[:1.8.0_121]
at 
org.opendaylight.openflowplugin.impl.protocol.serialization.instructions.AbstractActionInstructionSerializer.lambda$writeActions$2(AbstractActionInstructionSerializer.java:44)
at java.util.Optional.map(Optional.java:215)[:1.8.0_121]
at