Re: [openflowplugin-dev] [release] [controller-dev] Migrating inventory/topology models

[Faseela K via Lists.Opendaylight.Org]

Robert,
   Sorry if I have missed some part of this discussion.
   As these models are having heavy impact on netvirt and genius, just curious.
   
https://git.opendaylight.org/gerrit/#/c/controller/+/84251/1/opendaylight/model/model-inventory/src/main/yang/opendaylight-inventory.yang
The patch is talking only about removal of the deprecated status.
Is that the only change we are talking about? Or are we really doing the 
migration in openflowplugin, which was the initial decision years back?
Thanks,
Faseela

-Original Message-
From: release  On Behalf Of Robert Varga
Sent: Thursday, September 5, 2019 11:49 PM
To: Anil Vishnoi 
Cc: disc...@lists.opendaylight.org; controller-...@lists.opendaylight.org; 
mdsal-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
rele...@lists.opendaylight.org
Subject: Re: [release] [controller-dev] Migrating inventory/topology models

[+ discuss, mdsal-dev]

On 05/09/2019 19:24, Anil Vishnoi wrote:
> As for the next steps, I think we need to migrate these models to
> openflowplugin, where they can be maintained, as that world is the only
> place that really uses them.
> 
> As far as upstream OpenDaylight is concern this make sense to me, but 
> we need to be careful about the downstream consumer. Downstream user 
> who just use core ODL projects (Controller, yangtools, mdsal,aaa) to 
> develop their standalone application might be using these models, so 
> this movement will break them and to solve this they will have to put 
> dependency on openflowpluing, which they might not want.

That is a valid concern, yes.

The answer really lies in packaging, as if you are using karaf, you will have 
openflowplugin-features added to you distribution. Those would not be 
installed, but will bloat the distro & confuse the users.

On the other hand, every feature we build is a separate repository, so while 
you'd depend on openflowplugin-artifacts, you do not have to depend on 
openflowplugin-features -- I think.

Without Karaf, you depend on whatever you like, so yeah, you get tied up with 
OFP release cycle, but other than that there should not be a problem.

As far as those models are concerned, platform (mdsal/controller/netc) position 
on them can be summed up as:

Migrate to using ietf-network(-topology), which are shipped from MD-SAL for a 
year now. There are RFC8345 standard and are not expected to make in the 
foreseeable future.
As a further note, while performing that migration, also move away from using 
yang-ext.yang routed RPCs by switching to YANG 1.1 actions. Such models are not 
supported by legacy RESTCONF (which itself is deprecated), but are fully 
supported by RFC8040 RESTCONF (which is the only actively supported version).

On a related note, this discussion will also be coming up with relation to:

ietf-packet-fields
ietf-access-control-list
ietf-lisp-address-types
ietf-ted
ietf-topology
ietf-topology-isis
ietf-topology-l3-unicast-igp
ietf-topology-ospf

as MD-SAL will be gradually dropping at least those, which have been superseded 
by RFCs.

Regards,
Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#8754): 
https://lists.opendaylight.org/g/openflowplugin-dev/message/8754
Mute This Topic: https://lists.opendaylight.org/mt/34101878/21656
Group Owner: openflowplugin-dev+ow...@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/openflowplugin-dev/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Faseela K]

+1

From: openflowplugin-dev-boun...@lists.opendaylight.org 
 On Behalf Of Anil Belur
Sent: Tuesday, May 7, 2019 7:25 AM
To: Abhijit Kumbhare 
Cc:  ; 
openflowplugin-dev 
Subject: Re: [openflowplugin-dev] [OpenDaylight TSC] OpenFlow committer 
nomination : Gobinath Suganthan

+1

On Tue, May 7, 2019 at 4:00 AM Abhijit Kumbhare 
mailto:abhijitk...@gmail.com>> wrote:
TSC members - please vote on this thread.

On Mon, May 6, 2019 at 10:58 AM Luis Gomez 
mailto:ece...@gmail.com>> wrote:
+1


On May 6, 2019, at 10:57 AM, Anil Vishnoi 
mailto:vishnoia...@gmail.com>> wrote:

Given that we didn't get a chance to vote on Gobinath's committer nomination in 
last TSC meeting, can we please vote through mail thread please?

Thanks
Anil

On Wed, May 1, 2019 at 11:43 PM Anil Vishnoi 
mailto:vishnoia...@gmail.com>> wrote:
Hi Abhijit,

Sorry for the ast minute notice, is it possible to add agenda time in tomorrows 
tsc to vote for Gobinath's nomination as OpenFlow plugin committer?

If not, can we use this thread to vote on it ?

Thanks
Anil

-- Forwarded message -
From: Anil Vishnoi mailto:vishnoia...@gmail.com>>
Date: Wed, May 1, 2019 at 11:40 PM
Subject: Re: OpenFlow committer nomination : Gobinath Suganthan
To: Hema Gopalkrishnan 
mailto:hema.gopalkrish...@ericsson.com>>
Cc: Prasanna Huddar 
mailto:prasanna.hud...@ericsson.com>>, D 
Arunprakash mailto:d.arunprak...@ericsson.com>>, 
Shuva Kar mailto:shuva.jyoti.kar...@gmail.com>>, 
Abhijit Kumbhare mailto:abhijitk...@gmail.com>>, 
openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>

Thanks for the prompt reply folks. We got 6 votes out of 8 all in favor. I will 
propose this nomination to TSC for approval.

On Wed, May 1, 2019 at 9:12 PM Hema Gopalkrishnan 
mailto:hema.gopalkrish...@ericsson.com>> wrote:
+1

From: Prasanna Huddar
Sent: Thursday, May 2, 2019 8:58 AM
To: D Arunprakash 
mailto:d.arunprak...@ericsson.com>>; 
vishnoia...@gmail.com; Shuva Kar 
mailto:shuva.jyoti.kar...@gmail.com>>
Cc: Abhijit Kumbhare mailto:abhijitk...@gmail.com>>; 
openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Hema Gopalkrishnan 
mailto:hema.gopalkrish...@ericsson.com>>
Subject: Re: OpenFlow committer nomination : Gobinath Suganthan

+1

Sent from Workspace ONE Boxer

On 2 May 2019 08:51, D Arunprakash 
mailto:d.arunprak...@ericsson.com>> wrote:
+1

On 2 May 2019 08:32, Shuva Kar 
mailto:shuva.jyoti.kar...@gmail.com>> 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


--
Thanks
Anil


--
Thanks
Anil


--
Thanks
Anil
___
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
___
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

Re: [openflowplugin-dev] Review openflowplugin sodium-mri patches

[Faseela K]

Job #15 has failed at genius, Karthika is working on the patches for genius.

I have triggered #16 without skipping tests, so that Som can get an idea of the 
openflowplugin test failures.

Thanks,
Faseela

-Original Message-
From: Robert Varga  
Sent: Wednesday, April 10, 2019 2:35 PM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
Anil Vishnoi ; Faseela K 
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Review openflowplugin sodium-mri patches

On 10/04/2019 10:59, SOMASHEKHAR MANOHARA JAVALAGI wrote:
> Hi Robert,
> 

Hello Somashekhar,

> Openflowplugin build is passing in multipatch test run by Faseela.
> 
> https://jenkins.opendaylight.org/sandbox/job/integration-multipatch-te
> st-sodium/15/consoleFull
> 
> Is openflowplugin sodium-mri patches are completed or is there 
> anything pending?

Not quite -- as you noted, they are passing quick build, but they are failing 
when tests are enabled. I do not have the cycles to look at them further ;(

Regards,
Robert

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

[openflowplugin-dev] Review openflowplugin sodium-mri patches

[Faseela K]

Hello openflowplugin-devs,
   Could you please review the sodium-mri patches, and work on amending some of 
the incomplete patches as Robert has indicated?
   Your downstream is blocked, as these patches are not yet ready.
   We will need some time in netvirt, to stabilize the CSITs once your patches 
are all ready.
  
https://git.opendaylight.org/gerrit/#/q/topic:sodium-mri+(status:open)+project:openflowplugin
Thanks,
Faseela
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [integration-dev] Netvirt Apex jobs in jenkins - openflow stuck in starting state

[Faseela K]

Thanks Som!
Feel free to update the JIRA, if the patches are all merged!

Thanks,
Faseela

-Original Message-
From: SOMASHEKHAR MANOHARA JAVALAGI 
Sent: Tuesday, April 9, 2019 11:35 AM
To: Faseela K ; Jaya Priyadarshini 
; Jamo Luhrsen ; 
integration-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; D 
Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Faseela,

The csit 
https://jenkins.opendaylight.org/sandbox/job/Jaya-netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/2/
 is run with the patch fix and it is passing. We have merged the changes.

Regards,
Somashekhar

-Original Message-
From: Faseela K
Sent: Tuesday, April 9, 2019 11:31 AM
To: Jaya Priyadarshini ; SOMASHEKHAR MANOHARA 
JAVALAGI ; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Issue is tracked under :

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

Thanks,
Faseela

-Original Message-
From: Faseela K
Sent: Thursday, April 4, 2019 3:59 PM
To: Jaya Priyadarshini ; SOMASHEKHAR MANOHARA 
JAVALAGI ; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Thanks Jaya!

@Som : Could you please check if respective logs from ofp are there? Looks like 
it is not.

I think something is broken after the below patch got merged:

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

Thanks,
Faseela

-Original Message-
From: Jaya Priyadarshini
Sent: Thursday, April 4, 2019 2:16 PM
To: Faseela K ; SOMASHEKHAR MANOHARA JAVALAGI 
; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Faseela,

Here are the logs:

https://jenkins.opendaylight.org/sandbox/job/Jaya-netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/2/

Regards
Jaya

-Original Message-
From: Faseela K
Sent: Thursday, April 4, 2019 10:19 AM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
Jaya Priyadarshini ; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Jaya,
   Could you please supply logs for Sodium apex jobs with TRACE enabled for
  
org.opendaylight.openflowjava.protocol.impl.core.OpenflowDiagStatusProviderImpl 
?
Thanks,
Faseela

-Original Message-
From: SOMASHEKHAR MANOHARA JAVALAGI
Sent: Tuesday, April 2, 2019 9:05 PM
To: Jaya Priyadarshini ; Jamo Luhrsen 
; Faseela K ; 
integration-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; D 
Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Jaya,

We are sending status report of openflow service being operational to 
infrautils diagstatus service, as and when we receive systemBootReady 
notification.
This happened in 2 mins from the start of controller. We also report the status 
to be ERROR in case of some issues.
As I am not able to see any such logs, issue has to be checked at infrautils 
diagstatus service, whether it received status report properly.

Regards,
Somashekhar

-Original Message-
From: Jaya Priyadarshini
Sent: Tuesday, April 2, 2019 4:46 PM
To: Jamo Luhrsen ; SOMASHEKHAR MANOHARA JAVALAGI 
; Faseela K 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Som,

As  per info which u asked,
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/71/console-timestamp.log.gz

ODL is started at
07:22:10  2019-03-31 07:22:10,517 INFO: Starting Opendaylight on node 
overcloud-controller-0.opnfvlf.org

And it is checking if all bundles came up at around this time.
08:32:41  
==
08:32:41  01_l2 :: Test suite to verify packet flows between vm instances.  

08:32:41  
==

Regards
Jaya
-Original Message-
From: Jamo Luhrsen 
Sent: Monday, April 1, 2019 9:34 PM
To: SOMASHEKHAR MANOHARA

Re: [openflowplugin-dev] [integration-dev] Netvirt Apex jobs in jenkins - openflow stuck in starting state

[Faseela K]

Issue is tracked under :

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

Thanks,
Faseela

-Original Message-
From: Faseela K 
Sent: Thursday, April 4, 2019 3:59 PM
To: Jaya Priyadarshini ; SOMASHEKHAR MANOHARA 
JAVALAGI ; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Thanks Jaya!

@Som : Could you please check if respective logs from ofp are there? Looks like 
it is not.

I think something is broken after the below patch got merged:

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

Thanks,
Faseela

-Original Message-
From: Jaya Priyadarshini
Sent: Thursday, April 4, 2019 2:16 PM
To: Faseela K ; SOMASHEKHAR MANOHARA JAVALAGI 
; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Faseela,

Here are the logs:

https://jenkins.opendaylight.org/sandbox/job/Jaya-netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/2/

Regards
Jaya

-Original Message-
From: Faseela K
Sent: Thursday, April 4, 2019 10:19 AM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
Jaya Priyadarshini ; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Jaya,
   Could you please supply logs for Sodium apex jobs with TRACE enabled for
  
org.opendaylight.openflowjava.protocol.impl.core.OpenflowDiagStatusProviderImpl 
?
Thanks,
Faseela

-Original Message-
From: SOMASHEKHAR MANOHARA JAVALAGI
Sent: Tuesday, April 2, 2019 9:05 PM
To: Jaya Priyadarshini ; Jamo Luhrsen 
; Faseela K ; 
integration-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; D 
Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Jaya,

We are sending status report of openflow service being operational to 
infrautils diagstatus service, as and when we receive systemBootReady 
notification.
This happened in 2 mins from the start of controller. We also report the status 
to be ERROR in case of some issues.
As I am not able to see any such logs, issue has to be checked at infrautils 
diagstatus service, whether it received status report properly.

Regards,
Somashekhar

-Original Message-
From: Jaya Priyadarshini
Sent: Tuesday, April 2, 2019 4:46 PM
To: Jamo Luhrsen ; SOMASHEKHAR MANOHARA JAVALAGI 
; Faseela K 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Som,

As  per info which u asked,
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/71/console-timestamp.log.gz

ODL is started at
07:22:10  2019-03-31 07:22:10,517 INFO: Starting Opendaylight on node 
overcloud-controller-0.opnfvlf.org

And it is checking if all bundles came up at around this time.
08:32:41  
==
08:32:41  01_l2 :: Test suite to verify packet flows between vm instances.  

08:32:41  
==

Regards
Jaya
-Original Message-
From: Jamo Luhrsen 
Sent: Monday, April 1, 2019 9:34 PM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
Faseela K ; Jaya Priyadarshini 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: Re: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

something is broken.

Looks like the failures are only there in sodium. here is a karaf log from job 
#71 failure:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/71/controller_sos/sosreport-controllerreport-20190331083711/opt/opendaylight/data/log/karaf.log.gz

you can see some WARN messages in TracingBroker which seem to just repeat.

the controller is up for at least 10m before the actual failure is finally 
noted. In a neon job I just checked, the same validation is completed in 3s.

JamO



On 4/1/19 4:44 AM, SOMASHEKHAR MANOHARA JAVALAGI wrote:
> Hi Faseela,
> 
> Karaf is started at Mar 31, 2019 7:23:59 AM.
> 
> Once all the bundles are up, we are registering to SystemReadyMonitor 
> by 2019-03-31T07:25:31,172
> 

Re: [openflowplugin-dev] [integration-dev] Netvirt Apex jobs in jenkins - openflow stuck in starting state

[Faseela K]

Thanks Jaya!

@Som : Could you please check if respective logs from ofp are there? Looks like 
it is not.

I think something is broken after the below patch got merged:

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

Thanks,
Faseela

-Original Message-
From: Jaya Priyadarshini 
Sent: Thursday, April 4, 2019 2:16 PM
To: Faseela K ; SOMASHEKHAR MANOHARA JAVALAGI 
; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Faseela,

Here are the logs:

https://jenkins.opendaylight.org/sandbox/job/Jaya-netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/2/

Regards
Jaya

-Original Message-
From: Faseela K
Sent: Thursday, April 4, 2019 10:19 AM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
Jaya Priyadarshini ; Jamo Luhrsen 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Jaya,
   Could you please supply logs for Sodium apex jobs with TRACE enabled for
  
org.opendaylight.openflowjava.protocol.impl.core.OpenflowDiagStatusProviderImpl 
?
Thanks,
Faseela

-Original Message-
From: SOMASHEKHAR MANOHARA JAVALAGI
Sent: Tuesday, April 2, 2019 9:05 PM
To: Jaya Priyadarshini ; Jamo Luhrsen 
; Faseela K ; 
integration-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; D 
Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Jaya,

We are sending status report of openflow service being operational to 
infrautils diagstatus service, as and when we receive systemBootReady 
notification.
This happened in 2 mins from the start of controller. We also report the status 
to be ERROR in case of some issues.
As I am not able to see any such logs, issue has to be checked at infrautils 
diagstatus service, whether it received status report properly.

Regards,
Somashekhar

-Original Message-
From: Jaya Priyadarshini
Sent: Tuesday, April 2, 2019 4:46 PM
To: Jamo Luhrsen ; SOMASHEKHAR MANOHARA JAVALAGI 
; Faseela K 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Som,

As  per info which u asked,
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/71/console-timestamp.log.gz

ODL is started at
07:22:10  2019-03-31 07:22:10,517 INFO: Starting Opendaylight on node 
overcloud-controller-0.opnfvlf.org

And it is checking if all bundles came up at around this time.
08:32:41  
==
08:32:41  01_l2 :: Test suite to verify packet flows between vm instances.  

08:32:41  
==

Regards
Jaya
-Original Message-
From: Jamo Luhrsen 
Sent: Monday, April 1, 2019 9:34 PM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
Faseela K ; Jaya Priyadarshini 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: Re: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

something is broken.

Looks like the failures are only there in sodium. here is a karaf log from job 
#71 failure:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/71/controller_sos/sosreport-controllerreport-20190331083711/opt/opendaylight/data/log/karaf.log.gz

you can see some WARN messages in TracingBroker which seem to just repeat.

the controller is up for at least 10m before the actual failure is finally 
noted. In a neon job I just checked, the same validation is completed in 3s.

JamO



On 4/1/19 4:44 AM, SOMASHEKHAR MANOHARA JAVALAGI wrote:
> Hi Faseela,
> 
> Karaf is started at Mar 31, 2019 7:23:59 AM.
> 
> Once all the bundles are up, we are registering to SystemReadyMonitor 
> by 2019-03-31T07:25:31,172
> 
> After 16 seconds we are receiving onSystemBootready notification at
> 2019-03-31T07:25:47,219
> 
> Immediately within a second we are marking openflow service status as 
> operational at 2019-03-31T07:25:48,709
> 
> As bundles coming up is taking more time, we are finding delay in operational 
> status change of openflow service.
> 
> Regards,
> 
> Somashekhar
> 
> *From:* openflowplugin-dev-boun...@lists.opendaylight.org
>  *On Behalf Of 

Re: [openflowplugin-dev] [integration-dev] Netvirt Apex jobs in jenkins - openflow stuck in starting state

[Faseela K]

Jaya,
   Could you please supply logs for Sodium apex jobs with TRACE enabled for
  
org.opendaylight.openflowjava.protocol.impl.core.OpenflowDiagStatusProviderImpl 
?
Thanks,
Faseela

-Original Message-
From: SOMASHEKHAR MANOHARA JAVALAGI 
Sent: Tuesday, April 2, 2019 9:05 PM
To: Jaya Priyadarshini ; Jamo Luhrsen 
; Faseela K ; 
integration-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; D 
Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Jaya,

We are sending status report of openflow service being operational to 
infrautils diagstatus service, as and when we receive systemBootReady 
notification.
This happened in 2 mins from the start of controller. We also report the status 
to be ERROR in case of some issues.
As I am not able to see any such logs, issue has to be checked at infrautils 
diagstatus service, whether it received status report properly.

Regards,
Somashekhar

-Original Message-
From: Jaya Priyadarshini
Sent: Tuesday, April 2, 2019 4:46 PM
To: Jamo Luhrsen ; SOMASHEKHAR MANOHARA JAVALAGI 
; Faseela K 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: RE: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

Hi Som,

As  per info which u asked,
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/71/console-timestamp.log.gz

ODL is started at
07:22:10  2019-03-31 07:22:10,517 INFO: Starting Opendaylight on node 
overcloud-controller-0.opnfvlf.org

And it is checking if all bundles came up at around this time.
08:32:41  
==
08:32:41  01_l2 :: Test suite to verify packet flows between vm instances.  

08:32:41  
==

Regards
Jaya
-Original Message-
From: Jamo Luhrsen 
Sent: Monday, April 1, 2019 9:34 PM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
Faseela K ; Jaya Priyadarshini 
; integration-...@lists.opendaylight.org; 
netvirt-...@lists.opendaylight.org; D Arunprakash 
Cc: openflowplugin-dev 
Subject: Re: [integration-dev] [openflowplugin-dev] Netvirt Apex jobs in 
jenkins - openflow stuck in starting state

something is broken.

Looks like the failures are only there in sodium. here is a karaf log from job 
#71 failure:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium/71/controller_sos/sosreport-controllerreport-20190331083711/opt/opendaylight/data/log/karaf.log.gz

you can see some WARN messages in TracingBroker which seem to just repeat.

the controller is up for at least 10m before the actual failure is finally 
noted. In a neon job I just checked, the same validation is completed in 3s.

JamO



On 4/1/19 4:44 AM, SOMASHEKHAR MANOHARA JAVALAGI wrote:
> Hi Faseela,
> 
> Karaf is started at Mar 31, 2019 7:23:59 AM.
> 
> Once all the bundles are up, we are registering to SystemReadyMonitor 
> by 2019-03-31T07:25:31,172
> 
> After 16 seconds we are receiving onSystemBootready notification at
> 2019-03-31T07:25:47,219
> 
> Immediately within a second we are marking openflow service status as 
> operational at 2019-03-31T07:25:48,709
> 
> As bundles coming up is taking more time, we are finding delay in operational 
> status change of openflow service.
> 
> Regards,
> 
> Somashekhar
> 
> *From:* openflowplugin-dev-boun...@lists.opendaylight.org
>  *On Behalf Of 
> *Faseela K
> *Sent:* Monday, April 1, 2019 12:43 PM
> *To:* Jaya Priyadarshini ;
> integration-...@lists.opendaylight.org;
> netvirt-...@lists.opendaylight.org; D Arunprakash 
> 
> *Cc:* openflowplugin-dev 
> *Subject:* Re: [openflowplugin-dev] Netvirt Apex jobs in jenkins - 
> openflow stuck in starting state
> 
> Arun,
> 
>     Any idea when this can happen?
> 
>     System Ready State says all bundles have come up, but OFP is still in 
> starting state.
> 
> Thanks,
> 
> Faseela
> 
> *From:* netvirt-dev-boun...@lists.opendaylight.org
> <mailto:netvirt-dev-boun...@lists.opendaylight.org>
>  <mailto:netvirt-dev-boun...@lists.opendaylight.org>> *On Behalf Of 
> *Jaya Priyadarshini
> *Sent:* Monday, April 1, 2019 12:41 PM
> *To:* integration-...@lists.opendaylight.org
> <mailto:integration-...@lists.opendaylight.org>;
> netvirt-...@lists.opendaylight.org
> <mailto:netvirt-...@lists.opendaylight.org>
> *Subject:* [netvirt-dev] Apex jobs in jenkins
> 
> Here is the apex jobs status.
> 
> Success
> 
>   
> 
> 100%
> <http

Re: [openflowplugin-dev] Netvirt Apex jobs in jenkins - openflow stuck in starting state

[Faseela K]

Arun,
   Any idea when this can happen?
   System Ready State says all bundles have come up, but OFP is still in 
starting state.
Thanks,
Faseela

From: netvirt-dev-boun...@lists.opendaylight.org 
 On Behalf Of Jaya Priyadarshini
Sent: Monday, April 1, 2019 12:41 PM
To: integration-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org
Subject: [netvirt-dev] Apex jobs in jenkins

Here is the apex jobs status.
[Success]

[100%]

netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-fluorine

8 hr 19 min - 
#142

18 days - 
#123

1 hr 0 min

25 / 25 passed [https://jenkins.opendaylight.org/releng/plugin/robot/robot.png]



[Success]

[100%]

netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-neon

15 hr - 
#158

11 days - 
#148

52 min

25 / 25 passed [https://jenkins.opendaylight.org/releng/plugin/robot/robot.png]



[In progress]

[0%]

netvirt-csit-1node-0cmb-1ctl-2cmp-apex-queens-upstream-snat-conntrack-sodium

23 hr - 
#71

16 days - 
#40

1 hr 36 min

0 / 25 passed [https://jenkins.opendaylight.org/releng/plugin/robot/robot.png]


3rd failure is due to following reason

[?1l>[?2004lTimestamp: Sun Mar 31 08:33:15 UTC 2019 Node IP Address: /127.0.0.1 
System is operational: false System ready state: ACTIVE
OPENFLOW : STARTING (INITIALIZING) ___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [opendaylight-dev] How exactly OVS dispatch the Packet_In messages among different ODL controllers?

[Faseela K]

OVS also has nicira extensions where we can specify controller-id or IP in an 
“output to controller” action.
I am not sure whether this extension has made itself to any of the mainstream 
OVS releases.

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
 On Behalf Of Gobinath .
Sent: Tuesday, February 26, 2019 12:18 PM
To: openflowplugin-dev ; 
lin-jint...@outlook.com
Cc: d...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [opendaylight-dev] How exactly OVS dispatch 
the Packet_In messages among different ODL controllers?

Hi Lin,

From the Openflowplugin documentation,

• Master: All synchronous and asynchronous messages are sent to the master 
controller. This controller has write privileges on the switch.
• Slave: Only synchronous messages are sent to this controller. Slave 
controllers have only read privileges on the switch.

So, the PacketIn messages (asynchronous msg) are sent only to the master 
controller.

But when the “Equal” role (ref below) is enabled (“enable-equal-role=true”  in 
openflowplugin.cfg), the device will send all asynchronous event messages (e.g 
packet_in) to all the controllers, but openflowplugin will drop these events 
for the controller instances that is internally not owning the device ,ie, not 
the EOS master.

• Equal: When the equal role is assigned to a controller, it has the same 
privileges as the master controller. By default, a controller is assigned the 
equal role when it first connects to the switch.

Thanks and Regards,
Gobinath

From: 
openflowplugin-dev-boun...@lists.opendaylight.org
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Abhijit Kumbhare
Sent: Tuesday, February 26, 2019 5:36 AM
To: JINTING LIN mailto:lin-jint...@outlook.com>>; 
openflowplugin-dev@lists.opendaylight.org
Cc: d...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [opendaylight-dev] How exactly OVS dispatch 
the Packet_In messages among different ODL controllers?

Adding OpenFlow Plugin.


On Mon, Feb 25, 2019 at 3:56 PM JINTING LIN 
mailto:lin-jint...@outlook.com>> wrote:
Hi everyone,

I am going to develop a load balancing application with ODL and OVS. But I am
not so sure about how exactly OVS dispatch the Packet_In messages among 
different
controllers.

The OpenFlow Switch Specification 1.5.1 only specifies that the OVS should 
connect
to all configured controllers ("When OpenFlow operation is initiated, the switch
must connect to all controllers it is configured with"), and the switch 
migration
process is initiated by (one) controller ("The hand-over between controllers is
initiated by the controllers themselves").

Thus, if a OVS has to send a large number of Packet_In messages to controller
due to the arrival of numerous flows. There could be several different methods:
1. Send all Packet_In messages to only one (master, or currently configured) 
controller?
2. Send all Packet_In messages to all controllers?
3. All controllers receive a separated part of these messages?
4. other method?
I am not so sure what it is going to happen.

I am glad to receive any reply, discussion and guidance on my question.

stormlin
2019-02-25

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

Re: [openflowplugin-dev] Non-compliant mail – action required, contact dm...@ericsson.se : Re: Humbly requesting review and merge of 4 changes

[Faseela K]

This is the JIRA :
https://jira.opendaylight.org/browse/TSC-186

Genius CSIT issues seem to be resolved now.

Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Thursday, January 17, 2019 6:56 PM
To: SOMASHEKHAR MANOHARA JAVALAGI ; 
odlparent-dev ; Kitt, Stephen 
; Robert Varga 
Cc: Faseela K ; D Arunprakash 
; Gobinath . ; Anil Vishnoi 
; ece...@gmail.com; openflowplugin-dev 

Subject: Re: Non-compliant mail – action required, contact dm...@ericsson.se : 
Re: [openflowplugin-dev] Humbly requesting review and merge of 4 changes

Robert, Stephen,

can you clarify if the odlparent/mdsal version bump issue you mentioned in the 
Kernel call before yesterday which you said affects distribution is meanwhile 
resolved? If not, could that be causing CSIT failures which genius and 
openflowplugin are currently reporting? Which JIRA issue tracks the respective 
work, and is this something you are actively working on?

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


On Thu, Jan 17, 2019 at 7:04 AM SOMASHEKHAR MANOHARA JAVALAGI 
mailto:somashekhar.manohara.javal...@ericsson.com>>
 wrote:
Hi Luis,

We are seeing lot of EntityOwnershipChange errors upon receiving ownership 
change notification at the time of csit test case failures.
The notification received is not in proper state.

2019-01-10T19:30:13,312 | ERROR | 
opendaylight-cluster-data-akka.actor.default-dispatcher-3 | 
DOMEntityOwnershipListenerAdapter | 355 - 
org.opendaylight.mdsal.eos-binding-adapter - 3.0.3 | Error converting DOM 
entity ID 
/(urn:opendaylight:params:xml:ns:yang:mdsal:core:general-entity?revision=2015-09-30)entity/entity[{(urn:opendaylight:params:xml:ns:yang:mdsal:core:general-entity?revision=2015-09-30)name=openflow:209795042481734}]
 to binding InstanceIdentifier
java.lang.NullPointerException: null
at 
org.opendaylight.openflowplugin.applications.deviceownershipservice.impl.DeviceOwnershipServiceImpl.ownershipChanged(DeviceOwnershipServiceImpl.java:73)
 ~[?:?]
at 
org.opendaylight.mdsal.eos.binding.dom.adapter.DOMEntityOwnershipListenerAdapter.ownershipChanged(DOMEntityOwnershipListenerAdapter.java:45)
 [355:org.opendaylight.mdsal.eos-binding-adapter:3.0.3]
at 
org.opendaylight.controller.cluster.datastore.entityownership.EntityOwnershipListenerActor.onEntityOwnershipChanged(EntityOwnershipListenerActor.java:44)
 [299:org.opendaylight.controller.sal-distributed-datastore:1.9.0.SNAPSHOT]
at 
org.opendaylight.controller.cluster.datastore.entityownership.EntityOwn

Are there any issues with the csit test setup or it could be due to neon 
odlparent version bumps as Faseela suggested.

Regards,
Somashekhar

From: Faseela K
Sent: Thursday, January 17, 2019 9:25 AM
To: D Arunprakash 
mailto:d.arunprak...@ericsson.com>>; Michael 
Vorburger mailto:vorbur...@redhat.com>>; Gobinath . 
mailto:gobin...@ericsson.com>>; Anil Vishnoi 
mailto:vishnoia...@gmail.com>>; SOMASHEKHAR MANOHARA 
JAVALAGI 
mailto:somashekhar.manohara.javal...@ericsson.com>>
Cc: openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>
Subject: RE: Non-compliant mail – action required, contact 
dm...@ericsson.se<mailto:dm...@ericsson.se> : Re: [openflowplugin-dev] Humbly 
requesting review and merge of 4 changes

I think the neon odlparent version bumps are not yet complete, was seeing 
issues with genius CSIT in master as well.

Thanks,
Faseela

From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of D 
Arunprakash
Sent: Thursday, January 17, 2019 8:17 AM
To: Michael Vorburger mailto:vorbur...@redhat.com>>; 
Gobinath . mailto:gobin...@ericsson.com>>; Anil Vishnoi 
mailto:vishnoia...@gmail.com>>; SOMASHEKHAR MANOHARA 
JAVALAGI 
mailto:somashekhar.manohara.javal...@ericsson.com>>
Cc: openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>
Subject: Non-compliant mail – action required, contact 
dm...@ericsson.se<mailto:dm...@ericsson.se> : Re: [openflowplugin-dev] Humbly 
requesting review and merge of 4 changes

@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 
mailto:d.arunprak...@ericsson.com>>; Gobinath . 
mailto:gobin...@ericsson.com>>; Anil Vishnoi 
mailto:vishnoia...@gmail.com>>
Cc: openflowplugin-dev 
mailto:openflowplug

Re: [openflowplugin-dev] Non-compliant mail – action required, contact dm...@ericsson.se : Re: Humbly requesting review and merge of 4 changes

[Faseela K]

I think the neon odlparent version bumps are not yet complete, was seeing 
issues with genius CSIT in master as well.

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of D 
Arunprakash
Sent: Thursday, January 17, 2019 8:17 AM
To: Michael Vorburger ; Gobinath . 
; Anil Vishnoi ; SOMASHEKHAR 
MANOHARA JAVALAGI 
Cc: openflowplugin-dev 
Subject: Non-compliant mail – action required, contact dm...@ericsson.se : Re: 
[openflowplugin-dev] Humbly requesting review and merge of 4 changes

@SOMASHEKHAR MANOHARA 
JAVALAGI, openflowplugin 
csit seems to unstable in master, could you please check it?

@Michael Vorburger, 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 
mailto:d.arunprak...@ericsson.com>>; Gobinath . 
mailto:gobin...@ericsson.com>>; Anil Vishnoi 
mailto:vishnoia...@gmail.com>>
Cc: openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>
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 | 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] [genius-dev] StackOverflowError - openflowplugin.applications.arbitratorreconciliation

[Faseela K]

Thanks Gobinath for the fix!

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

Thanks,
Faseela

From: genius-dev-boun...@lists.opendaylight.org 
[mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela K
Sent: Thursday, August 16, 2018 1:18 PM
To: openflowplugin-dev@lists.opendaylight.org
Cc: genius-...@lists.opendaylight.org
Subject: [genius-dev] StackOverflowError - 
openflowplugin.applications.arbitratorreconciliation

Hello openflowplugin team,
   I got the below ERROR in karaf logs for one of the genius CSIT runs.
   Could you please check?

   
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-gate-all-neon/1/odl_1/odl1_karaf.log.gz


   2018-08-16T06:30:48,701 | ERROR | Framework stop   | BeanRecipe  
 | 76 - org.apache.aries.blueprint.core - 1.8.3 | The blueprint bean 
arbitratorReconciliationManager in bundle 
org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.8.0.SNAPSHOT
 incorrectly threw an exception from its destroy method.
java.lang.StackOverflowError: null
at 
java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1012) 
~[?:?]
at 
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?]
at 
org.opendaylight.openflowplugin.applications.reconciliation.impl.ReconciliationManagerImpl.decideResultState(ReconciliationManagerImpl.java:73)
 ~[?:?]
at 
org.opendaylight.openflowplugin.applications.reconciliation.impl.ReconciliationManagerImpl.lambda$registerService$2(ReconciliationManagerImpl.java:65)
 ~[?:?]

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

[openflowplugin-dev] StackOverflowError - openflowplugin.applications.arbitratorreconciliation

[Faseela K]

Hello openflowplugin team,
   I got the below ERROR in karaf logs for one of the genius CSIT runs.
   Could you please check?

   
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/genius-csit-1node-gate-all-neon/1/odl_1/odl1_karaf.log.gz


   2018-08-16T06:30:48,701 | ERROR | Framework stop   | BeanRecipe  
 | 76 - org.apache.aries.blueprint.core - 1.8.3 | The blueprint bean 
arbitratorReconciliationManager in bundle 
org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.8.0.SNAPSHOT
 incorrectly threw an exception from its destroy method.
java.lang.StackOverflowError: null
at 
java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1012) 
~[?:?]
at 
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?]
at 
org.opendaylight.openflowplugin.applications.reconciliation.impl.ReconciliationManagerImpl.decideResultState(ReconciliationManagerImpl.java:73)
 ~[?:?]
at 
org.opendaylight.openflowplugin.applications.reconciliation.impl.ReconciliationManagerImpl.lambda$registerService$2(ReconciliationManagerImpl.java:65)
 ~[?:?]

Thanks,
Faseela
___
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

[Faseela K]

Som,

Here are the logs as requested:
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/307/faseela-l2-netvirt-csit-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-oxygen/39/

Thanks,
Faseela

From: SOMASHEKHAR MANOHARA JAVALAGI
Sent: Wednesday, August 01, 2018 12:16 PM
To: Faseela K ; Vishal Thapar 
Cc: D Arunprakash ; Anil Vishnoi 
; Gobinath . ; Sam Hague 
; Dayavanti Gopal Kamath 
; Jamo Luhrsen ; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

Hi Faseela,

We analyzed the logs and able to see that Table miss entry is missing for table 
60. We are not able to see any success/failure future callback for the missing 
flow.
I have added further logs in openflowplugin in patch 
https://git.opendaylight.org/gerrit/#/c/74717/.
Can you please run the CSIT on the same.

Regards,
Somashekhar

From: Faseela K
Sent: Tuesday, July 31, 2018 9:17 PM
To: Vishal Thapar mailto:vtha...@redhat.com>>; SOMASHEKHAR 
MANOHARA JAVALAGI 
mailto:somashekhar.manohara.javal...@ericsson.com>>
Cc: D Arunprakash 
mailto:d.arunprak...@ericsson.com>>; Anil Vishnoi 
mailto:vishnoia...@gmail.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>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: RE: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

Som/Arun,
   Have updated netvirt CSIT with  information below as per Vishal’s inputs, 
and issue has been reproduced with DEBUG logs as per your suggestion.
   I have updated the JIRA with link to new logs.
Thanks,
Faseela

From: Vishal Thapar [mailto:vtha...@redhat.com]
Sent: Thursday, July 26, 2018 10:50 PM
To: Faseela K mailto:faseel...@ericsson.com>>
Cc: D Arunprakash 
mailto:d.arunprak...@ericsson.com>>; Anil Vishnoi 
mailto:vishnoia...@gmail.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>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

Hi Faseela,

Things to check:

1. Which odl is master for this switch and is it master for any other switch?
2. Is the flow present in config DS?
3. What was showsvc status for this ODL node?

Regards,
Vishal.

On Thu, Jul 26, 2018 at 10:40 PM, Faseela K 
mailto:faseel...@ericsson.com>> wrote:
Taking a look at the logs, i can see the below log line in 
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/260/faseela-l2-netvirt-csit-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-oxygen/18/odl_1/odl1_karaf.log.gz
10 mins before the test suite starts :

2018-07-25T23:00:41,688 | INFO | pool-241-thread-1 | 
WeightedCentralizedSwitchScheduler | 361 - 
org.opendaylight.netvirt.natservice-impl - 0.6.3.SNAPSHOT | addSwitch: Adding 
167740445697660 dpnId to switchWeightsMap

2018-07-25T23:00:42,274 | DEBUG | epollEventLoopGroup-9-1 | SalFlowServiceImpl 
| 385 - org.opendaylight.openflowplugin.impl - 0.6.3.SNAPSHOT | Flow add with 
id=DHCPTableMissFlowForExternalTunnel finished without error

But the flow is not present on the switch when the suite starts.

We have 3 OVS in the test, but i see only this flow-id log for 2 switches. 
Anyways the compute in question, is  167740445697660, so let us assume that the 
flow was getting pushed for the same, but doesn't show up on switch. But there 
are different failures showing up in the logs including the below one. Let me 
know if this could impact:


2018-07-25T23:01:09,328 | ERROR | 
opendaylight-cluster-data-notification-dispatcher-97 | DefaultConfigPusher | 
378 - org.opendaylight.openflowplugin.applications.of-switch-config-pusher - 
0.6.3.SNAPSHOT | Future (eventually) failed: addFlow 
org.opendaylight.controller.md.sal.dom.api.DOMRpcImplementationNotAvailableException:
 No implementation of RPC 
AbsoluteSchemaPath{path=[(urn:opendaylight:module:config?revision=2014-10-15)set-config]}
 available at 
org.opendaylight.controller.md.sal.dom.broker.impl.RoutedDOMRpcRoutingTableEntry.invokeRpc(RoutedDOMRpcRoutingTableEntry.java:85)
 [229:org.opendaylight.controller.sal-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:178)
 [229:org.opendaylight.controller.sal-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
 [229:org.opendaylight.controller.sal-broker-impl:1.7.3.SNAPSHOT] at 
Proxybb8ecb

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

[Faseela K]

Som/Arun,
   Have updated netvirt CSIT with  information below as per Vishal’s inputs, 
and issue has been reproduced with DEBUG logs as per your suggestion.
   I have updated the JIRA with link to new logs.
Thanks,
Faseela

From: Vishal Thapar [mailto:vtha...@redhat.com]
Sent: Thursday, July 26, 2018 10:50 PM
To: Faseela K 
Cc: D Arunprakash ; Anil Vishnoi 
; Gobinath . ; Sam Hague 
; Dayavanti Gopal Kamath 
; Jamo Luhrsen ; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

Hi Faseela,

Things to check:

1. Which odl is master for this switch and is it master for any other switch?
2. Is the flow present in config DS?
3. What was showsvc status for this ODL node?

Regards,
Vishal.

On Thu, Jul 26, 2018 at 10:40 PM, Faseela K 
mailto:faseel...@ericsson.com>> wrote:
Taking a look at the logs, i can see the below log line in 
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/260/faseela-l2-netvirt-csit-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-oxygen/18/odl_1/odl1_karaf.log.gz
10 mins before the test suite starts :

2018-07-25T23:00:41,688 | INFO | pool-241-thread-1 | 
WeightedCentralizedSwitchScheduler | 361 - 
org.opendaylight.netvirt.natservice-impl - 0.6.3.SNAPSHOT | addSwitch: Adding 
167740445697660 dpnId to switchWeightsMap

2018-07-25T23:00:42,274 | DEBUG | epollEventLoopGroup-9-1 | SalFlowServiceImpl 
| 385 - org.opendaylight.openflowplugin.impl - 0.6.3.SNAPSHOT | Flow add with 
id=DHCPTableMissFlowForExternalTunnel finished without error

But the flow is not present on the switch when the suite starts.

We have 3 OVS in the test, but i see only this flow-id log for 2 switches. 
Anyways the compute in question, is  167740445697660, so let us assume that the 
flow was getting pushed for the same, but doesn't show up on switch. But there 
are different failures showing up in the logs including the below one. Let me 
know if this could impact:


2018-07-25T23:01:09,328 | ERROR | 
opendaylight-cluster-data-notification-dispatcher-97 | DefaultConfigPusher | 
378 - org.opendaylight.openflowplugin.applications.of-switch-config-pusher - 
0.6.3.SNAPSHOT | Future (eventually) failed: addFlow 
org.opendaylight.controller.md.sal.dom.api.DOMRpcImplementationNotAvailableException:
 No implementation of RPC 
AbsoluteSchemaPath{path=[(urn:opendaylight:module:config?revision=2014-10-15)set-config]}
 available at 
org.opendaylight.controller.md.sal.dom.broker.impl.RoutedDOMRpcRoutingTableEntry.invokeRpc(RoutedDOMRpcRoutingTableEntry.java:85)
 [229:org.opendaylight.controller.sal-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:178)
 [229:org.opendaylight.controller.sal-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:102)
 [229:org.opendaylight.controller.sal-broker-impl:1.7.3.SNAPSHOT] at 
Proxybb8ecbf1_eb9d_4480_a18e_4a2007f00a3c.invokeRpc(Unknown Source) [?:?] at 
Proxy40f45215_a726_4be9_ac6b_649862163662.invokeRpc(Unknown Source) [?:?] at 
org.opendaylight.controller.md.sal.binding.impl.RpcServiceAdapter.invoke0(RpcServiceAdapter.java:68)
 [226:org.opendaylight.controller.sal-binding-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.md.sal.binding.impl.RpcServiceAdapter.access$000(RpcServiceAdapter.java:46)
 [226:org.opendaylight.controller.sal-binding-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.md.sal.binding.impl.RpcServiceAdapter$RpcInvocationStrategy.invoke(RpcServiceAdapter.java:165)
 [226:org.opendaylight.controller.sal-binding-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.md.sal.binding.impl.RpcServiceAdapter.invoke(RpcServiceAdapter.java:99)
 [226:org.opendaylight.controller.sal-binding-broker-impl:1.7.3.SNAPSHOT] at 
com.sun.proxy.$Proxy113.setConfig(Unknown Source) 
[388:org.opendaylight.openflowplugin.model.flow-service:0.6.3.SNAPSHOT] at 
org.opendaylight.openflowplugin.openflow.ofswitch.config.DefaultConfigPusher.onDataTreeChanged(DefaultConfigPusher.java:84)
 
[378:org.opendaylight.openflowplugin.applications.of-switch-config-pusher:0.6.3.SNAPSHOT]
 at 
org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataTreeChangeListenerAdapter.onDataTreeChanged(BindingDOMDataTreeChangeListenerAdapter.java:41)
 [226:org.opendaylight.controller.sal-binding-broker-impl:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.cluster.datastore.DataTreeChangeListenerActor.dataChanged(DataTreeChangeListenerActor.java:67)
 [239:org.opendaylight.controller.sal-distributed-datastore:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.cluster.datastore.DataTreeChangeListenerActor.handleReceive(DataTreeChangeListenerActor.java:41)
 [239:org.opendaylight.controller.sal-distributed-datastore:1.7.3.SNAPSHOT] at 
org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onR

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

[Faseela K]

:2.5.11] at 
akka.dispatch.Mailbox.exec(Mailbox.scala:234) 
[42:com.typesafe.akka.actor:2.5.11] at 
akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) 
[42:com.typesafe.akka.actor:2.5.11] at 
akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) 
[42:com.typesafe.akka.actor:2.5.11] at 
akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) 
[42:com.typesafe.akka.actor:2.5.11] at 
akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) 
[42:com.typesafe.akka.actor:2.5.11]

From: Faseela K
Sent: Thursday, July 26, 2018 7:50 AM
To: D Arunprakash ; 'Anil Vishnoi' 

Cc: 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

Arun,
   Here are the logs with DEBUG enabled.
   
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/260/faseela-l2-netvirt-csit-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-oxygen/18/
   This time, table 18 entry is missing.
Thanks,
Faseela

From: Faseela K
Sent: Wednesday, July 25, 2018 4:34 PM
To: D Arunprakash 
mailto:d.arunprak...@ericsson.com>>; Anil Vishnoi 
mailto:vishnoia...@gmail.com>>
Cc: 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: RE: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

Arun,
   I have enabled the requested TRACE logs and running the CSIT now.
   Ever since I enabled the TRACEs it has not failed :).
   Let us see if the issue gets reproduced in another 24 hours.
Thanks,
Faseela

From: D Arunprakash
Sent: Wednesday, July 25, 2018 7:53 AM
To: Faseela K mailto:faseel...@ericsson.com>>; Anil 
Vishnoi mailto:vishnoia...@gmail.com>>
Cc: 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: RE: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

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 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: 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] Netvirt Cluster CSIT : Table Miss Entry programming failing randomly

[Faseela K]

Arun,
   Here are the logs with DEBUG enabled.
   
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/builder-copy-sandbox-logs/260/faseela-l2-netvirt-csit-3node-0cmb-1ctl-2cmp-openstack-queens-upstream-stateful-oxygen/18/
   This time, table 18 entry is missing.
Thanks,
Faseela

From: Faseela K
Sent: Wednesday, July 25, 2018 4:34 PM
To: D Arunprakash ; Anil Vishnoi 

Cc: 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

Arun,
   I have enabled the requested TRACE logs and running the CSIT now.
   Ever since I enabled the TRACEs it has not failed :).
   Let us see if the issue gets reproduced in another 24 hours.
Thanks,
Faseela

From: D Arunprakash
Sent: Wednesday, July 25, 2018 7:53 AM
To: Faseela K mailto:faseel...@ericsson.com>>; Anil 
Vishnoi mailto:vishnoia...@gmail.com>>
Cc: 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: RE: Netvirt Cluster CSIT : Table Miss Entry programming failing 
randomly

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 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: 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] Netvirt Cluster CSIT : Table Miss Entry programming failing randomly

[Faseela K]

Arun,
   I have enabled the requested TRACE logs and running the CSIT now.
   Ever since I enabled the TRACEs it has not failed :).
   Let us see if the issue gets reproduced in another 24 hours.
Thanks,
Faseela

From: D Arunprakash
Sent: Wednesday, July 25, 2018 7:53 AM
To: Faseela K ; Anil Vishnoi 
Cc: 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

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 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: 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] Netvirt Cluster CSIT : Table Miss Entry programming failing randomly

[Faseela K]

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 
Cc: D Arunprakash ; Gobinath . 
; Sam Hague ; Dayavanti Gopal Kamath 
; Jamo Luhrsen ; 
Vishal Thapar ; 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] Jenkins job failure with SFT failure (while resolving odl-serviceutils-tool)

[Faseela K]

Gobi,
  Are you still facing this issue?
Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Gobinath .
Sent: Friday, July 06, 2018 6:06 PM
To: infrautils-...@lists.opendaylight.org
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: [openflowplugin-dev] Jenkins job failure with SFT failure (while 
resolving odl-serviceutils-tool)

Hi,

The Jenkins build for my patch (https://git.opendaylight.org/gerrit/#/c/70184/ 
) has started failing recently with errors in resolving 
"odl-serviceutils-tools" module.
I had the dependency on "odl-serviceutils-tools" earlier too but I've started 
facing this issue recently.
Jenkins log : 
https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/97/console

Unable to resolve root: missing requirement [root] osgi.identity; 
osgi.identity=odl-openflowplugin-app-arbitratorreconciliation; 
type=karaf.feature; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; 
filter:="(&(osgi.identity=odl-openflowplugin-app-arbitratorreconciliation)(type=karaf.feature)(version>=0.7.0.SNAPSHOT)(version<=0.7.0.SNAPSHOT))"
 [caused by: Unable to resolve 
odl-openflowplugin-app-arbitratorreconciliation/0.7.0.SNAPSHOT: missing 
requirement [odl-openflowplugin-app-arbitratorreconciliation/0.7.0.SNAPSHOT] 
osgi.identity; 
osgi.identity=org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl;
 type=osgi.bundle; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; 
resolution:=mandatory [caused by: Unable to resolve 
org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.7.0.SNAPSHOT:
 missing requirement 
[org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.7.0.SNAPSHOT]
 osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.opendaylight.serviceutils.upgrade)(version>=0.2.0)(!(version>=1.0.0)))"
 [caused by: Unable to resolve 
org.opendaylight.serviceutils.upgrade/0.2.0.SNAPSHOT: missing requirement 
[org.opendaylight.serviceutils.upgrade/0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity="root#odl-serviceutils-tools-0.2.0.SNAPSHOT"; 
type=karaf.subsystem; version="[0,0.0.0]"; resolution:=mandatory [caused by: 
Unable to resolve root#odl-serviceutils-tools-0.2.0.SNAPSHOT: missing 
requirement [root#odl-serviceutils-tools-0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-serviceutils-tools; type=karaf.feature; 
version="[0.2.0.SNAPSHOT,0.2.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-serviceutils-tools/0.2.0.SNAPSHOT: missing requirement 
[odl-serviceutils-tools/0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-infrautils-metrics; type=karaf.feature; 
version="[1.4.0.SNAPSHOT,1.4.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-infrautils-metrics/1.4.0.SNAPSHOT: missing requirement 
[odl-infrautils-metrics/1.4.0.SNAPSHOT] osgi.identity; 
osgi.identity=io.dropwizard.metrics.jvm; type=osgi.bundle; 
version="[4.0.2,4.0.2]"; resolution:=mandatory [caused by: Unable to resolve 
io.dropwizard.metrics.jvm/4.0.2: missing requirement 
[io.dropwizard.metrics.jvm/4.0.2] osgi.wiring.package; 
filter:="(osgi.wiring.package=com.sun.management)"]]]

I could see that a recent version bump was done for the 
io.dropwizard.metrics.jvm recently in infrautils 
(https://git.opendaylight.org/gerrit/#/c/72223/ ).
Currently I have a dependency on the odl-serviceutils-tools which in turn has 
dependency on odl-infrautils-metrics (which contains the above module).
Could someone from infrautils/serviceutils help with this?

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

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

[Faseela K]

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] [sfc-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

Anyone knows how to fix odl-interface-rpc.yang with minimal changes so that 
this serialization issue goes off?
I have taken a look, I cannot see an easy way without adding all augmentations, 
and then using ActionConverterUtil.java in all applications using this RPC to 
convert them back.

Thanks,
Faseela

-Original Message-
From: Jaime Caamaño Ruiz [mailto:jcaam...@suse.de] 
Sent: Tuesday, July 10, 2018 3:27 PM
To: Tom Pantelis ; Deepthi V V 
Cc: Faseela K ; Robert Varga ; 
genius-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org; sfc-...@lists.opendaylight.org; 
Vishal Thapar 
Subject: Re: [sfc-dev] [openflowplugin-dev] [mdsal-dev] 
IncorrectNestingException on SFC when sing OFP model

Hello Tom, Robert

> However the serialization bypass was "broken" in the process. I think 
> this explains the difference.

Are patches [1] and [2] intention to restore this bypass?
I tested [3] a multipatch build [4] with both patches and still get the  
IncorrectNestingException.

BR
Jaime.

[1] https://git.opendaylight.org/gerrit/#/c/73824/
[2] https://git.opendaylight.org/gerrit/#/c/73825/
[3] 
https://jenkins.opendaylight.org/sandbox/job/netvirt-csit-1node-openstack-queens-sfc-fluorine/1/
[4] 
https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/160

-Original Message-
From: Tom Pantelis 
To: Deepthi V V , jcaam...@suse.de
Cc: Faseela K , Robert Varga , 
genius-...@lists.opendaylight.org ,
mdsal-...@lists.opendaylight.org ,
openflowplugin-dev@lists.opendaylight.org , sfc-...@lists.opendaylight.org , Vishal Thapar 
Subject: Re: [sfc-dev] [openflowplugin-dev] [mdsal-dev] 
IncorrectNestingException on SFC when sing OFP model
Date: Mon, 9 Jul 2018 14:10:48 -0400



On Mon, Jul 9, 2018 at 1:41 PM, Tom Pantelis 
wrote:
> 
> On Mon, Jul 9, 2018 at 6:29 AM, Deepthi V V  > wrote:
> > Hi Robert, Faseela,
> > 
> > That does explain our situation.
> > But doesn't the blueprint extensions odl:rpc-implementation and 
> > odl:rpc-service supposed to register and fetch the service through 
> > RPC-registry?
> 
> These were recently changed to use the mdsal APIs.  
> 

 netvirt uses the blueprint RPC ext which have been converted to use the mdsal 
APIs so the serialization bypass that Robert mentioned takes effect and masks 
the underlying app-side issue. sfc uses the controller RpcProviderRegistry API 
whose DOM impls were recently changed to proxy to the mdsal APIs. However the 
serialization bypass was "broken" in the process. I think this explains the 
difference.
 
>  
> > Thanks,
> > Deepthi
> > 
> > -Original Message-
> > From: Robert Varga 
> > Sent: Monday, July 09, 2018 3:36 PM
> > To: Faseela K ; Deepthi V V  > icsson.com>; Vishal Thapar 
> > Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.or 
> > g; genius-...@lists.opendaylight.org; Tom Pantelis  > il.com>; openflowplugin-dev@lists.opendaylight.org
> > Subject: Re: [openflowplugin-dev] [mdsal-dev] 
> > IncorrectNestingException on SFC when sing OFP model
> > 
> > On 09/07/18 11:55, Faseela K wrote:
> > > Netvirt uses blueprint wiring and injects the
> > odlInterfaceRpcService,
> > > where as sfc uses interfaceManagerRpcService = 
> > > rpcProviderRegistry.getRpcService(OdlInterfaceRpcService.class);
> > > 
> > > Robert indicated that so netvirt is bypassing MD-SAL, as it is
> > taking the service implementation from OSGi Service Registry, and 
> > that explains why the failure is happening only for sfc.
> > 
> > Correct.
> > 
> > Note that netvirt approach requires the service to be local, whereas 
> > the SFC approach is location agnostic (the service can be located 
> > anywhere in the cluster).
> > 
> > Regards,
> > Robert
> > 

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

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

Just an FYI, we were discussing on IRC why this works for netvirt still.

Netvirt uses blueprint wiring and injects the odlInterfaceRpcService, where as 
sfc uses interfaceManagerRpcService = 
rpcProviderRegistry.getRpcService(OdlInterfaceRpcService.class);

Robert indicated that so netvirt is bypassing MD-SAL, as it is taking the 
service implementation from OSGi Service Registry, and that explains why the 
failure is happening only for sfc.

Thanks,
Faseela

-Original Message-
From: Faseela K 
Sent: Monday, July 09, 2018 3:11 PM
To: Deepthi V V ; 'Robert Varga' ; 
'Vishal Thapar' 
Cc: 'sfc-...@lists.opendaylight.org' ; 
'mdsal-...@lists.opendaylight.org' ; 
'genius-...@lists.opendaylight.org' ; 'Tom 
Pantelis' ; 'openflowplugin-dev@lists.opendaylight.org' 

Subject: RE: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

JIRA raised : https://jira.opendaylight.org/browse/GENIUS-174

Jaime told the local RPC shortcut was added back on Friday, and so, he is 
checking if CSIT is back to normal right now.

We will anyways track this JIRA to fix our rpc model.

Thanks,
Faseela

-Original Message-
From: Faseela K 
Sent: Monday, July 09, 2018 2:23 PM
To: Deepthi V V ; Robert Varga ; Vishal 
Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

Thanks Deepthi!
We are not using routed-rpc. This clarifies why we never hit this error before 
on 3 node.

But to me, why it works for netvirt l2/l3 is still not clear.

Thanks,
Faseela

-Original Message-
From: Deepthi V V 
Sent: Monday, July 09, 2018 2:19 PM
To: Faseela K ; Robert Varga ; Vishal 
Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

Hi Robert,

Just to clarify, IF getEgressActions RPC was a routed RPC implementation, the 
issue should have been visible earlier because it would go through DOM 
serialization process.
Since it is a global RPC, the call/response always happened on the same node 
and because of the shortcut, there were no errors.

Thanks,
Deepthi

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org 
 On Behalf Of Faseela K
Sent: Monday, July 09, 2018 1:36 PM
To: Robert Varga ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

I understand that for the single node scenarios, there is a change introduced 
on June 26th, due to which this will fail now.

But, are you saying for cross-node, this would have never worked even before?
We have been using the same code on 3 node, from Beryllium timeframe.


Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, July 09, 2018 1:22 PM
To: Faseela K ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: Re: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

On 09/07/18 06:58, Faseela K wrote:
> Also, what do you mean by " this code/model is broken and will not work 
> in an cross-node invocation and needs to be fixed." I did not understand 
> "cross-node" in this context, the failure is in 1 node SFC CSIT.

The nicira extensions are augmentations, which are targeted at inventory 
datastore only, therefore their use in the output of the RPC is not
valid: they are not port of the model in that place.

As I explained, for single node scenarios, where the RPC invoker and RPC 
implementation are on the same node, this happened to work because of the 
shortcut I mentioned.

As soon as the application invoking the RPC and the implementation are not on 
the same node this will not work, as the output must go through NormalizedNodes 
and there is no corresponding schema.

Regards,
Robert

___
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] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

JIRA raised : https://jira.opendaylight.org/browse/GENIUS-174

Jaime told the local RPC shortcut was added back on Friday, and so, he is 
checking if CSIT is back to normal right now.

We will anyways track this JIRA to fix our rpc model.

Thanks,
Faseela

-Original Message-
From: Faseela K 
Sent: Monday, July 09, 2018 2:23 PM
To: Deepthi V V ; Robert Varga ; Vishal 
Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

Thanks Deepthi!
We are not using routed-rpc. This clarifies why we never hit this error before 
on 3 node.

But to me, why it works for netvirt l2/l3 is still not clear.

Thanks,
Faseela

-Original Message-
From: Deepthi V V 
Sent: Monday, July 09, 2018 2:19 PM
To: Faseela K ; Robert Varga ; Vishal 
Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

Hi Robert,

Just to clarify, IF getEgressActions RPC was a routed RPC implementation, the 
issue should have been visible earlier because it would go through DOM 
serialization process.
Since it is a global RPC, the call/response always happened on the same node 
and because of the shortcut, there were no errors.

Thanks,
Deepthi

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org 
 On Behalf Of Faseela K
Sent: Monday, July 09, 2018 1:36 PM
To: Robert Varga ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

I understand that for the single node scenarios, there is a change introduced 
on June 26th, due to which this will fail now.

But, are you saying for cross-node, this would have never worked even before?
We have been using the same code on 3 node, from Beryllium timeframe.


Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, July 09, 2018 1:22 PM
To: Faseela K ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: Re: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

On 09/07/18 06:58, Faseela K wrote:
> Also, what do you mean by " this code/model is broken and will not work 
> in an cross-node invocation and needs to be fixed." I did not understand 
> "cross-node" in this context, the failure is in 1 node SFC CSIT.

The nicira extensions are augmentations, which are targeted at inventory 
datastore only, therefore their use in the output of the RPC is not
valid: they are not port of the model in that place.

As I explained, for single node scenarios, where the RPC invoker and RPC 
implementation are on the same node, this happened to work because of the 
shortcut I mentioned.

As soon as the application invoking the RPC and the implementation are not on 
the same node this will not work, as the output must go through NormalizedNodes 
and there is no corresponding schema.

Regards,
Robert

___
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] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

Thanks Deepthi!
We are not using routed-rpc. This clarifies why we never hit this error before 
on 3 node.

But to me, why it works for netvirt l2/l3 is still not clear.

Thanks,
Faseela

-Original Message-
From: Deepthi V V 
Sent: Monday, July 09, 2018 2:19 PM
To: Faseela K ; Robert Varga ; Vishal 
Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

Hi Robert,

Just to clarify, IF getEgressActions RPC was a routed RPC implementation, the 
issue should have been visible earlier because it would go through DOM 
serialization process.
Since it is a global RPC, the call/response always happened on the same node 
and because of the shortcut, there were no errors.

Thanks,
Deepthi

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org 
 On Behalf Of Faseela K
Sent: Monday, July 09, 2018 1:36 PM
To: Robert Varga ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; Tom Pantelis ; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC 
when sing OFP model

I understand that for the single node scenarios, there is a change introduced 
on June 26th, due to which this will fail now.

But, are you saying for cross-node, this would have never worked even before?
We have been using the same code on 3 node, from Beryllium timeframe.


Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, July 09, 2018 1:22 PM
To: Faseela K ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: Re: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

On 09/07/18 06:58, Faseela K wrote:
> Also, what do you mean by " this code/model is broken and will not work 
> in an cross-node invocation and needs to be fixed." I did not understand 
> "cross-node" in this context, the failure is in 1 node SFC CSIT.

The nicira extensions are augmentations, which are targeted at inventory 
datastore only, therefore their use in the output of the RPC is not
valid: they are not port of the model in that place.

As I explained, for single node scenarios, where the RPC invoker and RPC 
implementation are on the same node, this happened to work because of the 
shortcut I mentioned.

As soon as the application invoking the RPC and the implementation are not on 
the same node this will not work, as the output must go through NormalizedNodes 
and there is no corresponding schema.

Regards,
Robert

___
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] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

I understand that for the single node scenarios, there is a change introduced 
on June 26th, due to which this will fail now.

But, are you saying for cross-node, this would have never worked even before?
We have been using the same code on 3 node, from Beryllium timeframe.


Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, July 09, 2018 1:22 PM
To: Faseela K ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: Re: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

On 09/07/18 06:58, Faseela K wrote:
> Also, what do you mean by " this code/model is broken and will not work 
> in an cross-node invocation and needs to be fixed." I did not understand 
> "cross-node" in this context, the failure is in 1 node SFC CSIT.

The nicira extensions are augmentations, which are targeted at inventory 
datastore only, therefore their use in the output of the RPC is not
valid: they are not port of the model in that place.

As I explained, for single node scenarios, where the RPC invoker and RPC 
implementation are on the same node, this happened to work because of the 
shortcut I mentioned.

As soon as the application invoking the RPC and the implementation are not on 
the same node this will not work, as the output must go through NormalizedNodes 
and there is no corresponding schema.

Regards,
Robert

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

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

Hi Robert,

   The nicira extension used here is "resubmit to table=220" which is actually 
filled by genius interfacemanager and returned to the application who invokes 
the RPC. This is common for SFC and netvirt l2/l3.

Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, July 09, 2018 1:24 PM
To: Faseela K ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: Re: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

On 09/07/18 09:02, Faseela K wrote:
>Also, I could not still understand why the same RPC works for netvirt 
> l2/l3, but not for sfc.

netvirt l2/l3 is obviously not using nicira extensions, but only the actions 
directly defined in action-list.

Regards,
Robert

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

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

   Jaime, Please raise a JIRA to track this.
   Robert, please let us know if we need to fix the genius data models, or we 
are talking about some fix in mdsal.
   It was not clear to me from the previous mail.
   Also, I could not still understand why the same RPC works for netvirt l2/l3, 
but not for sfc.

Thanks,
Faseela

-Original Message-
From: Faseela K 
Sent: Monday, July 09, 2018 10:29 AM
To: Robert Varga ; Vishal Thapar 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: RE: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

Robert,
I still have a question, why is SFC CSIT alone failing in this case?
The same RPC is very heavily used by l2/l3 in netvirt and I see no issues 
with the CSIT from June 26th.
  
https://jenkins.opendaylight.org/releng/view/netvirt/job/netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/
Also, what do you mean by " this code/model is broken and will not work in 
an cross-node invocation and needs to be fixed." I did not understand 
"cross-node" in this context, the failure is in 1 node SFC CSIT.
Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Monday, July 09, 2018 8:06 AM
To: Vishal Thapar ; Faseela K 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: Re: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

On 09/07/18 01:26, Robert Varga wrote:
> On 07/07/18 06:20, Vishal Thapar wrote:
>> possible the yang definition for this one was incorrect and some 
>> recent patch is now catching the violation.
> output {
> uses action:action-list;
> }
> 
> i.e. this is a separate instantiation of action-list, without 
> mentioning any nicira extensions: their presence is not valid in this context.

As to what is catching the violation, it is the fact that since 
https://git.opendaylight.org/gerrit/#/c/73376/ (merged on Jun 26th) the binding 
adapter shortcut, which skips serialization when the RPC is local and between 
two binding users, is no longer effective, hence the data is bounced via DOM.

While we will restore the shortcut, this code/model is broken and will not work 
in an cross-node invocation and needs to be fixed.

Regards,
Robert

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

Re: [openflowplugin-dev] Jenkins job failure with SFT failure (while resolving odl-serviceutils-tool)

[Faseela K]

As Michael is on PTO,
Stephen, do you think the below patch of bumping dropwizard.metrics has any 
impact on the failure what Gobi is seeing?

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

Thanks,
Faseela

From: Faseela K
Sent: Friday, July 06, 2018 6:10 PM
To: 'Gobinath .' ; infrautils-...@lists.opendaylight.org
Cc: openflowplugin-dev@lists.opendaylight.org; genius-...@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] Jenkins job failure with SFT failure (while 
resolving odl-serviceutils-tool)

+genius-dev

From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Gobinath .
Sent: Friday, July 06, 2018 6:06 PM
To: 
infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: [openflowplugin-dev] Jenkins job failure with SFT failure (while 
resolving odl-serviceutils-tool)

Hi,

The Jenkins build for my patch (https://git.opendaylight.org/gerrit/#/c/70184/ 
) has started failing recently with errors in resolving 
"odl-serviceutils-tools" module.
I had the dependency on "odl-serviceutils-tools" earlier too but I've started 
facing this issue recently.
Jenkins log : 
https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/97/console

Unable to resolve root: missing requirement [root] osgi.identity; 
osgi.identity=odl-openflowplugin-app-arbitratorreconciliation; 
type=karaf.feature; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; 
filter:="(&(osgi.identity=odl-openflowplugin-app-arbitratorreconciliation)(type=karaf.feature)(version>=0.7.0.SNAPSHOT)(version<=0.7.0.SNAPSHOT))"
 [caused by: Unable to resolve 
odl-openflowplugin-app-arbitratorreconciliation/0.7.0.SNAPSHOT: missing 
requirement [odl-openflowplugin-app-arbitratorreconciliation/0.7.0.SNAPSHOT] 
osgi.identity; 
osgi.identity=org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl;
 type=osgi.bundle; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; 
resolution:=mandatory [caused by: Unable to resolve 
org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.7.0.SNAPSHOT:
 missing requirement 
[org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.7.0.SNAPSHOT]
 osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.opendaylight.serviceutils.upgrade)(version>=0.2.0)(!(version>=1.0.0)))"
 [caused by: Unable to resolve 
org.opendaylight.serviceutils.upgrade/0.2.0.SNAPSHOT: missing requirement 
[org.opendaylight.serviceutils.upgrade/0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity="root#odl-serviceutils-tools-0.2.0.SNAPSHOT"; 
type=karaf.subsystem; version="[0,0.0.0]"; resolution:=mandatory [caused by: 
Unable to resolve root#odl-serviceutils-tools-0.2.0.SNAPSHOT: missing 
requirement [root#odl-serviceutils-tools-0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-serviceutils-tools; type=karaf.feature; 
version="[0.2.0.SNAPSHOT,0.2.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-serviceutils-tools/0.2.0.SNAPSHOT: missing requirement 
[odl-serviceutils-tools/0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-infrautils-metrics; type=karaf.feature; 
version="[1.4.0.SNAPSHOT,1.4.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-infrautils-metrics/1.4.0.SNAPSHOT: missing requirement 
[odl-infrautils-metrics/1.4.0.SNAPSHOT] osgi.identity; 
osgi.identity=io.dropwizard.metrics.jvm; type=osgi.bundle; 
version="[4.0.2,4.0.2]"; resolution:=mandatory [caused by: Unable to resolve 
io.dropwizard.metrics.jvm/4.0.2: missing requirement 
[io.dropwizard.metrics.jvm/4.0.2] osgi.wiring.package; 
filter:="(osgi.wiring.package=com.sun.management)"]]]

I could see that a recent version bump was done for the 
io.dropwizard.metrics.jvm recently in infrautils 
(https://git.opendaylight.org/gerrit/#/c/72223/ ).
Currently I have a dependency on the odl-serviceutils-tools which in turn has 
dependency on odl-infrautils-metrics (which contains the above module).
Could someone from infrautils/serviceutils help with this?

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

Re: [openflowplugin-dev] [mdsal-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

Robert,
I still have a question, why is SFC CSIT alone failing in this case?
The same RPC is very heavily used by l2/l3 in netvirt and I see no issues 
with the CSIT from June 26th.
  
https://jenkins.opendaylight.org/releng/view/netvirt/job/netvirt-csit-1node-openstack-queens-upstream-stateful-fluorine/
Also, what do you mean by " this code/model is broken and will not work in 
an cross-node invocation and needs to be fixed." I did not understand 
"cross-node" in this context, the failure is in 1 node SFC CSIT.
Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, July 09, 2018 8:06 AM
To: Vishal Thapar ; Faseela K 
Cc: sfc-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
Tom Pantelis 
Subject: Re: [mdsal-dev] [openflowplugin-dev] IncorrectNestingException on SFC 
when sing OFP model

On 09/07/18 01:26, Robert Varga wrote:
> On 07/07/18 06:20, Vishal Thapar wrote:
>> possible the yang definition for this one was incorrect and some 
>> recent patch is now catching the violation.
> output {
> uses action:action-list;
> }
> 
> i.e. this is a separate instantiation of action-list, without 
> mentioning any nicira extensions: their presence is not valid in this context.

As to what is catching the violation, it is the fact that since 
https://git.opendaylight.org/gerrit/#/c/73376/ (merged on Jun 26th) the binding 
adapter shortcut, which skips serialization when the RPC is local and between 
two binding users, is no longer effective, hence the data is bounced via DOM.

While we will restore the shortcut, this code/model is broken and will not work 
in an cross-node invocation and needs to be fixed.

Regards,
Robert

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

Re: [openflowplugin-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

Jaime,
  I tried to analyze, but could not figure out why the RPC fails only in SFC.
  One quick question, is it failing only in some corner cases, or consistently 
failing across all usages in SFC?
Thanks,
Faseela

-Original Message-
From: Jaime Caamaño Ruiz [mailto:jcaam...@suse.de] 
Sent: Friday, July 06, 2018 2:29 PM
To: Faseela K ; genius-...@lists.opendaylight.org; 
mdsal-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org
Cc: sfc-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] IncorrectNestingException on SFC when sing 
OFP model

Hi Faseela

It is also hapenning in upstream nightly CSIT job [1] since 26th of June. This 
is coincidential with the odl-parent bump to 3.1.2. I checked for other commits 
though, and mdsals [2] seems related and around that time (@Robert).

[1] https://jenkins.opendaylight.org/releng/job/netvirt-csit-1node-open
stack-queens-sfc-fluorine/
[2] https://git.opendaylight.org/gerrit/#/c/72382/

BR
Jaime.

-Original Message-
From: Faseela K 
To: genius-...@lists.opendaylight.org , mdsal-...@lists.opendaylight.org 
, openflowplugin-dev@lists.opendaylight.org , jcaam...@suse.de
Cc: sfc-...@lists.opendaylight.org 
Subject: RE: [openflowplugin-dev] IncorrectNestingException on SFC when
sing OFPmodel
Date: Fri, 6 Jul 2018 02:24:14 +

Jaime,
   This is a very common RPC heavily used by NETVIRT L2/L3 as well, and I don't 
see any issues in netvirt CSIT as of now.
   We will check this and get back to you.
   Is this failure on any patch test, or the upstream nightly SFC CSIT job?
Thanks,
Faseela

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org [mailto:openflo 
wplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Jaime Caamaño Ruiz
Sent: Friday, July 06, 2018 1:16 AM
To: mdsal-...@lists.opendaylight.org; openflowplugin-dev@lists.opendayl 
ight.org; genius-...@lists.opendaylight.org
Cc: sfc-...@lists.opendaylight.org
Subject: [openflowplugin-dev] IncorrectNestingException on SFC when sing OFP 
model

Hello

We got this IncorrectNestingException [1] on SFC/Genius:

Caused by:
org.opendaylight.mdsal.binding.dom.codec.impl.IncorrectNestingException
: Supplied class interface
org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.
nicira.action.rev140714.nodes.node.table.flow.instructions.instruction.
instruction.apply.actions._case.apply.actions.action.action.NxActionReg
LoadNodesNodeTableFlowApplyActionsCase is not valid case in 
org.opendaylight.yang.gen.v1.urn.opendaylight.action.types.rev131112.ac
tion.Action

This is on a call to Genius IFM getEgressActionsForInterface RPC, it looks like 
the RPC output does not validate on serialization. 

I am not aware of any relevant changes recently. Respective bundle manifests 
seem fine compared with a local distro that works for me from couple of weeks 
back. 

Models, for reference, are [2-5]. 

Any thoughts/ideas?

Thanks,
Jaime.

[1] https://logs.opendaylight.org/sandbox/vex-yul-odl-jenkins-2/netvirt
-csit-1node-openstack-queens-sfc-fluorine/5/odl_1/odl1_karaf.log.gz
[2] https://github.com/opendaylight/openflowplugin/blob/master/extensio
n/openflowplugin-extension-nicira/src/main/yang/openflowplugin-
extension-nicira-action.yang#L1499
[3] https://github.com/opendaylight/openflowplugin/blob/master/model/mo
del-flow-base/src/main/yang/opendaylight-action-types.yang#L52
[4] https://github.com/opendaylight/openflowplugin/blob/master/model/mo
del-flow-base/src/main/yang/opendaylight-flow-types.yang#L99
[5] https://github.com/opendaylight/openflowplugin/blob/master/model/mo
del-flow-service/src/main/yang/flow-node-inventory.yang#L119
___
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] Jenkins job failure with SFT failure (while resolving odl-serviceutils-tool)

[Faseela K]

+genius-dev

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Gobinath .
Sent: Friday, July 06, 2018 6:06 PM
To: infrautils-...@lists.opendaylight.org
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: [openflowplugin-dev] Jenkins job failure with SFT failure (while 
resolving odl-serviceutils-tool)

Hi,

The Jenkins build for my patch (https://git.opendaylight.org/gerrit/#/c/70184/ 
) has started failing recently with errors in resolving 
"odl-serviceutils-tools" module.
I had the dependency on "odl-serviceutils-tools" earlier too but I've started 
facing this issue recently.
Jenkins log : 
https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/97/console

Unable to resolve root: missing requirement [root] osgi.identity; 
osgi.identity=odl-openflowplugin-app-arbitratorreconciliation; 
type=karaf.feature; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; 
filter:="(&(osgi.identity=odl-openflowplugin-app-arbitratorreconciliation)(type=karaf.feature)(version>=0.7.0.SNAPSHOT)(version<=0.7.0.SNAPSHOT))"
 [caused by: Unable to resolve 
odl-openflowplugin-app-arbitratorreconciliation/0.7.0.SNAPSHOT: missing 
requirement [odl-openflowplugin-app-arbitratorreconciliation/0.7.0.SNAPSHOT] 
osgi.identity; 
osgi.identity=org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl;
 type=osgi.bundle; version="[0.7.0.SNAPSHOT,0.7.0.SNAPSHOT]"; 
resolution:=mandatory [caused by: Unable to resolve 
org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.7.0.SNAPSHOT:
 missing requirement 
[org.opendaylight.openflowplugin.applications.arbitratorreconciliation-impl/0.7.0.SNAPSHOT]
 osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.opendaylight.serviceutils.upgrade)(version>=0.2.0)(!(version>=1.0.0)))"
 [caused by: Unable to resolve 
org.opendaylight.serviceutils.upgrade/0.2.0.SNAPSHOT: missing requirement 
[org.opendaylight.serviceutils.upgrade/0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity="root#odl-serviceutils-tools-0.2.0.SNAPSHOT"; 
type=karaf.subsystem; version="[0,0.0.0]"; resolution:=mandatory [caused by: 
Unable to resolve root#odl-serviceutils-tools-0.2.0.SNAPSHOT: missing 
requirement [root#odl-serviceutils-tools-0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-serviceutils-tools; type=karaf.feature; 
version="[0.2.0.SNAPSHOT,0.2.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-serviceutils-tools/0.2.0.SNAPSHOT: missing requirement 
[odl-serviceutils-tools/0.2.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-infrautils-metrics; type=karaf.feature; 
version="[1.4.0.SNAPSHOT,1.4.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-infrautils-metrics/1.4.0.SNAPSHOT: missing requirement 
[odl-infrautils-metrics/1.4.0.SNAPSHOT] osgi.identity; 
osgi.identity=io.dropwizard.metrics.jvm; type=osgi.bundle; 
version="[4.0.2,4.0.2]"; resolution:=mandatory [caused by: Unable to resolve 
io.dropwizard.metrics.jvm/4.0.2: missing requirement 
[io.dropwizard.metrics.jvm/4.0.2] osgi.wiring.package; 
filter:="(osgi.wiring.package=com.sun.management)"]]]

I could see that a recent version bump was done for the 
io.dropwizard.metrics.jvm recently in infrautils 
(https://git.opendaylight.org/gerrit/#/c/72223/ ).
Currently I have a dependency on the odl-serviceutils-tools which in turn has 
dependency on odl-infrautils-metrics (which contains the above module).
Could someone from infrautils/serviceutils help with this?

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

Re: [openflowplugin-dev] IncorrectNestingException on SFC when sing OFP model

[Faseela K]

Jaime,
   This is a very common RPC heavily used by NETVIRT L2/L3 as well, and I don't 
see any issues in netvirt CSIT as of now.
   We will check this and get back to you.
   Is this failure on any patch test, or the upstream nightly SFC CSIT job?
Thanks,
Faseela

-Original Message-
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Jaime 
Caamaño Ruiz
Sent: Friday, July 06, 2018 1:16 AM
To: mdsal-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org; genius-...@lists.opendaylight.org
Cc: sfc-...@lists.opendaylight.org
Subject: [openflowplugin-dev] IncorrectNestingException on SFC when sing OFP 
model

Hello

We got this IncorrectNestingException [1] on SFC/Genius:

Caused by:
org.opendaylight.mdsal.binding.dom.codec.impl.IncorrectNestingException
: Supplied class interface
org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.
nicira.action.rev140714.nodes.node.table.flow.instructions.instruction.
instruction.apply.actions._case.apply.actions.action.action.NxActionReg
LoadNodesNodeTableFlowApplyActionsCase is not valid case in 
org.opendaylight.yang.gen.v1.urn.opendaylight.action.types.rev131112.ac
tion.Action

This is on a call to Genius IFM getEgressActionsForInterface RPC, it looks like 
the RPC output does not validate on serialization. 

I am not aware of any relevant changes recently. Respective bundle manifests 
seem fine compared with a local distro that works for me from couple of weeks 
back. 

Models, for reference, are [2-5]. 

Any thoughts/ideas?

Thanks,
Jaime.

[1] 
https://logs.opendaylight.org/sandbox/vex-yul-odl-jenkins-2/netvirt-csit-1node-openstack-queens-sfc-fluorine/5/odl_1/odl1_karaf.log.gz
[2] 
https://github.com/opendaylight/openflowplugin/blob/master/extension/openflowplugin-extension-nicira/src/main/yang/openflowplugin-extension-nicira-action.yang#L1499
[3] 
https://github.com/opendaylight/openflowplugin/blob/master/model/model-flow-base/src/main/yang/opendaylight-action-types.yang#L52
[4] 
https://github.com/opendaylight/openflowplugin/blob/master/model/model-flow-base/src/main/yang/opendaylight-flow-types.yang#L99
[5] 
https://github.com/opendaylight/openflowplugin/blob/master/model/model-flow-service/src/main/yang/flow-node-inventory.yang#L119
___
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] [genius-dev] SnD with openflowplugin

[Faseela K]

Vishal :
https://jira.opendaylight.org/browse/GENIUS-108

No, I did not do anything for it ;)

Thanks,
Faseela

From: Vishal Thapar [mailto:vtha...@redhat.com]
Sent: Thursday, May 31, 2018 9:45 PM
To: Faseela K 
Cc: Sam Hague ; openflowplugin-dev 
; Michael Vorburger 
; D Arunprakash ; 
genius-...@lists.opendaylight.org
Subject: Re: [genius-dev] SnD with openflowplugin

Faseela,

Remember we had discussed Genius reporting ready status only once it was done 
with all of its own bring up, not just bundles. I think I had a wip patch for 
it offline and you were planning to take it to conclusion. Is that still in 
works/plan?

Regards,
Vishal.

On Thu, May 31, 2018 at 9:37 PM, Faseela K 
mailto:faseel...@ericsson.com>> wrote:
Sam,
   Openflowplugin listens for SystemReady notification from infrautils, before 
it opens up the 6653 port, and report status as “OPERATIONAL”.
   Genius reports datastore status as “OPERATIONAL” only when the config and 
operational datastore syncStatus is TRUE.(ofcourse this happens after the 
leader elections)
Thanks,
Faseela

From: Sam Hague [mailto:sha...@redhat.com<mailto:sha...@redhat.com>]
Sent: Thursday, May 31, 2018 8:58 PM
To: Faseela K mailto:faseel...@ericsson.com>>; 
openflowplugin-dev 
mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Michael Vorburger mailto:vorbur...@redhat.com>>; D 
Arunprakash mailto:d.arunprak...@ericsson.com>>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: SnD with openflowplugin

Faseela, Arun,

can you fill me in on what ofp implemented for the SnD? What does ofp wait for 
before it reports status back?

Also does the EOS or leader election happen before the ready status is reported?

Faseela, same question for genius.

Ultimate goal, is we are trying to understand if somewhere along the chain if 
the leader has been elected so that the SnD is more accurate for when a 
clustering setup is ready.

Thanks, Sam

___
genius-dev mailing list
genius-...@lists.opendaylight.org<mailto: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] SnD with openflowplugin

[Faseela K]

Sam,
   Openflowplugin listens for SystemReady notification from infrautils, before 
it opens up the 6653 port, and report status as “OPERATIONAL”.
   Genius reports datastore status as “OPERATIONAL” only when the config and 
operational datastore syncStatus is TRUE.(ofcourse this happens after the 
leader elections)
Thanks,
Faseela

From: Sam Hague [mailto:sha...@redhat.com]
Sent: Thursday, May 31, 2018 8:58 PM
To: Faseela K ; openflowplugin-dev 
; Michael Vorburger 
; D Arunprakash ; 
genius-...@lists.opendaylight.org
Subject: SnD with openflowplugin

Faseela, Arun,

can you fill me in on what ofp implemented for the SnD? What does ofp wait for 
before it reports status back?

Also does the EOS or leader election happen before the ready status is reported?

Faseela, same question for genius.

Ultimate goal, is we are trying to understand if somewhere along the chain if 
the leader has been elected so that the SnD is more accurate for when a 
clustering setup is ready.

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

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

[Faseela K]

Congrats 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] [genius-dev] Autorelease build failing while adding dependency on genius-srm from openflowplugin

[Faseela K]

We did not discuss this, wanted you to be there ☺

Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Tuesday, May 22, 2018 2:23 PM
To: Faseela K <faseel...@ericsson.com>
Cc: Muthukumaran K <muthukumara...@ericsson.com>; 
genius-...@lists.opendaylight.org; integration-...@lists.opendaylight.org; Luis 
Gomez <ece...@gmail.com>; openflowplugin-dev@lists.opendaylight.org
Subject: Re: [genius-dev] [openflowplugin-dev] Autorelease build failing while 
adding dependency on genius-srm from openflowplugin

On Wed, May 16, 2018 at 5:00 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Michael,
   Let us discuss this in tomorrow’s call, and arrive at a conclusion.

sorry I couldn't join the weekly project call last week - was this discussed?

I'm interested in this not so much for OFP (this thread), but because I may 
want to use the genius DataTreeEventCallbackRegistrar in project Neutron for 
https://jira.opendaylight.org/browse/NEUTRON-158, and if that happens, then we 
would have a similar problem...

Thanks,
Faseela

From: 
genius-dev-boun...@lists.opendaylight.org<mailto:genius-dev-boun...@lists.opendaylight.org>
 
[mailto:genius-dev-boun...@lists.opendaylight.org<mailto:genius-dev-boun...@lists.opendaylight.org>]
 On Behalf Of Michael Vorburger
Sent: Tuesday, May 15, 2018 2:55 PM
To: Muthukumaran K 
<muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Cc: 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 Luis Gomez <ece...@gmail.com<mailto:ece...@gmail.com>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [genius-dev] [openflowplugin-dev] Autorelease build failing while 
adding dependency on genius-srm from openflowplugin

Muthu, thanks for chiming in, but I am fundamentally against using any sort of 
"weakly typed hacks" to "work around" and "hide" what in effect ARE strong 
dependencies... so while I understand what you are getting at below from a 
technical PoV, they are total No Go, to me.

Genius project commiters: Do we want to propose the creation of a new Git repo 
that is part of the Genius project governance and move genius/tools and 
genius/srm there so that OFP can consume it?


On Tue, May 15, 2018 at 7:12 AM, Muthukumaran K 
<muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>> wrote:
One approach to handle the situation as below is to use a level of indirection 
using components which are very fundamental to Karaf and/or JVM so that hard 
dependencies are totally avoided. These approaches make the API semantics of 
SRM more event-based than explicit register-callback

Option 1 in this specific context :
SRM and OFP can communicate via EventAdmin wherein whenever SRM wants OFP to 
take an action, it just publishes a ‘notification’ to a pub-sub topic. So, SRM 
becomes eventadmin publisher and OFP becomes eventadmin subscriber

Option 2 in this specific context :
A bit compromised solution - using JMX. Following notify-react mechanism SRM 
fires a JMX notification and OFP listens and reacts

Pros :

1)  Across API boundary there is no explicit dependency

2)  Version management would not be an issue because both Option 1 and 
Option 2 utilize more fundamental (more fundamental than Offset-0) services of 
Karaf and/or JVM
Cons :

1)  We can use only simplet types as notification payloads and not rich 
structured objects which should be acceptable for most of usecases

Regards
Muthu



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 Michael Vorburger
Sent: Monday, May 14, 2018 10:35 PM
To: Luis Gomez <ece...@gmail.com<mailto:ece...@gmail.com>>
Cc: 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] [genius-dev] Autorelease build failing while 
adding dependency on genius-srm from openflowplugin

On Mon, May 14, 2018 at 6:59 PM, Luis Gomez 
<ece...@gmail.com<mailto:ece...@gmail.com>> wrote:

afaik we do not allow cycles between projects so this code may require new 
project (if this has different scope than original) or new repo to resolve the 
conflict.

Can you tell us more about the "new repo" option? If we could have a 2nd repo, 
which from a governance perspective is part of the existing genius project, to 
host 

Re: [openflowplugin-dev] [release] openflowplugin build failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

[Faseela K]

Robert,

  Issue was due to the below patch itself.
  But Tom got the fix in genius :  
https://git.opendaylight.org/gerrit/#/c/71581/
  With this I ran the multi-patch job again, but it failed in netconf this time.
  
https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/51/

Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Thursday, May 17, 2018 3:47 PM
To: Faseela K <faseel...@ericsson.com>; Anil Vishnoi <vishnoia...@gmail.com>; 
Michael Vorburger <vorbur...@redhat.com>
Cc: <t...@lists.opendaylight.org> <t...@lists.opendaylight.org>; 
openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; release 
(rele...@lists.opendaylight.org) <rele...@lists.opendaylight.org>; Tom Pantelis 
<tompante...@gmail.com>
Subject: Re: [release] [openflowplugin-dev] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Hello Faseela,

were you able to pin down the problem, or should we be reverting 
https://git.opendaylight.org/gerrit/#/c/71547/, which is the suspect?

Thanks,
Robert

On 16/05/18 13:28, Faseela K wrote:
> This job is stuck at the same place even now! L
> 
>  
> 
> *From:*Faseela K
> *Sent:* Wednesday, May 16, 2018 12:33 PM
> *To:* 'Anil Vishnoi' <vishnoia...@gmail.com>; 'Michael Vorburger'
> <vorbur...@redhat.com>
> *Cc:* '<t...@lists.opendaylight.org>' <t...@lists.opendaylight.org>; 
> 'openflowplugin-dev' <openflowplugin-dev@lists.opendaylight.org>;
> 'release (rele...@lists.opendaylight.org)' 
> <rele...@lists.opendaylight.org>
> *Subject:* RE: [openflowplugin-dev] [release] openflowplugin build 
> failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)
> 
>  
> 
> Multi patch job is stuck for quite some time at genius 
> DataBrokerFailureTest now.
> 
>  
> 
> https://jenkins.opendaylight.org/releng/job/integration-multipatch-tes
> t-fluorine/47/console
> 
>  
> 
> *03:26:41*---
> 
> *03:26:41* T E S T S
> 
> *03:26:41*---
> 
> *03:26:42*Running
> org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoClose
> ableModuleTest
> 
> *03:26:43*Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed: 1.288 sec - in
> org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoClose
> ableModuleTest
> 
> *03:26:43*Running
> org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestabl
> eListenerTest
> 
> *03:26:44*Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed: 0.643 sec - in
> org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestabl
> eListenerTest
> 
> *03:26:44*Running
> org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoor
> dinatorEventsWaiterTest
> 
> *03:26:47*Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time
> elapsed: 3.516 sec - in
> org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoor
> dinatorEventsWaiterTest
> 
> *03:26:47*Running
> org.opendaylight.genius.datastoreutils.testutils.tests.DataBrokerFailu
> resTest
> 
> https://jenkins.opendaylight.org/releng/static/f332478f/images/spinner
> .gif
> 
>  
> 
>  
> 
> Thanks,
> 
> Faseela
> 
>  
> 
> *From:*Faseela K
> *Sent:* Wednesday, May 16, 2018 10:55 AM
> *To:* Anil Vishnoi <vishnoia...@gmail.com 
> <mailto:vishnoia...@gmail.com>>; Michael Vorburger 
> <vorbur...@redhat.com <mailto:vorbur...@redhat.com>>
> *Cc:* <t...@lists.opendaylight.org <mailto:t...@lists.opendaylight.org>>
> <t...@lists.opendaylight.org <mailto:t...@lists.opendaylight.org>>;
> openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org
> <mailto:openflowplugin-dev@lists.opendaylight.org>>; release 
> (rele...@lists.opendaylight.org 
> <mailto:rele...@lists.opendaylight.org>)
> <rele...@lists.opendaylight.org 
> <mailto:rele...@lists.opendaylight.org>>
> *Subject:* RE: [openflowplugin-dev] [release] openflowplugin build 
> failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)
> 
>  
> 
> Thanks Anil..
> 
> I am monitoring the output to see if genius patch builds fine, else 
> will look into the failures!
> 
>  
> 
> Thanks,
> 
> Faseela
> 
>  
> 
> *From:*openflowplugin-dev-boun...@lists.opendaylight.org
> <mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
> [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] *On Behalf 
> Of *Anil Vishnoi
> *Sent:* Wednesday, May 16, 2018 10:53 AM
> *

Re: [openflowplugin-dev] [release] openflowplugin build failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

[Faseela K]

+integration-dev

Can someone please abort the below job? I am not getting permissions to do that.
There was a regression in genius, because of some changes recently merged in 
controller repo, which is getting fixed right now. The multi-patch job below is 
not getting timed-out and has been stuck for so long at the below point. I will 
merge the fix in genius, and then rebase the TSC-99 patch to run multi-patch 
job again.

Thanks,
Faseela

From: Faseela K
Sent: Wednesday, May 16, 2018 4:58 PM
To: 'Anil Vishnoi' <vishnoia...@gmail.com>; 'Michael Vorburger' 
<vorbur...@redhat.com>
Cc: '<t...@lists.opendaylight.org>' <t...@lists.opendaylight.org>; 
'openflowplugin-dev' <openflowplugin-dev@lists.opendaylight.org>; 'release 
(rele...@lists.opendaylight.org)' <rele...@lists.opendaylight.org>
Subject: RE: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

This job is stuck at the same place even now! ☹

From: Faseela K
Sent: Wednesday, May 16, 2018 12:33 PM
To: 'Anil Vishnoi' <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>; 
'Michael Vorburger' <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: '<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>' 
<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 'release 
(rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>)' 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subject: RE: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Multi patch job is stuck for quite some time at genius DataBrokerFailureTest 
now.

https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/47/console

03:26:41 ---
03:26:41  T E S T S
03:26:41 ---
03:26:42 Running 
org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoCloseableModuleTest
03:26:43 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.288 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoCloseableModuleTest
03:26:43 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestableListenerTest
03:26:44 Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.643 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestableListenerTest
03:26:44 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoordinatorEventsWaiterTest
03:26:47 Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.516 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoordinatorEventsWaiterTest
03:26:47 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.DataBrokerFailuresTest
[https://jenkins.opendaylight.org/releng/static/f332478f/images/spinner.gif]


Thanks,
Faseela

From: Faseela K
Sent: Wednesday, May 16, 2018 10:55 AM
To: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>; Michael 
Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: <t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>> 
<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 release 
(rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>) 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subject: RE: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Thanks Anil..
I am monitoring the output to see if genius patch builds fine, else will look 
into the failures!

Thanks,
Faseela

From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Anil 
Vishnoi
Sent: Wednesday, May 16, 2018 10:53 AM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: <t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>> 
<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 release 
(rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>) 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subje

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

[Faseela K]

Michael,
   Let us discuss this in tomorrow’s call, and arrive at a conclusion.
Thanks,
Faseela

From: genius-dev-boun...@lists.opendaylight.org 
[mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of Michael 
Vorburger
Sent: Tuesday, May 15, 2018 2:55 PM
To: Muthukumaran K ; 
genius-...@lists.opendaylight.org
Cc: integration-...@lists.opendaylight.org; Luis Gomez ; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [genius-dev] [openflowplugin-dev] Autorelease build failing while 
adding dependency on genius-srm from openflowplugin

Muthu, thanks for chiming in, but I am fundamentally against using any sort of 
"weakly typed hacks" to "work around" and "hide" what in effect ARE strong 
dependencies... so while I understand what you are getting at below from a 
technical PoV, they are total No Go, to me.

Genius project commiters: Do we want to propose the creation of a new Git repo 
that is part of the Genius project governance and move genius/tools and 
genius/srm there so that OFP can consume it?


On Tue, May 15, 2018 at 7:12 AM, Muthukumaran K 
> wrote:
One approach to handle the situation as below is to use a level of indirection 
using components which are very fundamental to Karaf and/or JVM so that hard 
dependencies are totally avoided. These approaches make the API semantics of 
SRM more event-based than explicit register-callback

Option 1 in this specific context :
SRM and OFP can communicate via EventAdmin wherein whenever SRM wants OFP to 
take an action, it just publishes a ‘notification’ to a pub-sub topic. So, SRM 
becomes eventadmin publisher and OFP becomes eventadmin subscriber

Option 2 in this specific context :
A bit compromised solution - using JMX. Following notify-react mechanism SRM 
fires a JMX notification and OFP listens and reacts

Pros :

1)  Across API boundary there is no explicit dependency

2)  Version management would not be an issue because both Option 1 and 
Option 2 utilize more fundamental (more fundamental than Offset-0) services of 
Karaf and/or JVM
Cons :

1)  We can use only simplet types as notification payloads and not rich 
structured objects which should be acceptable for most of usecases

Regards
Muthu



From: 
openflowplugin-dev-boun...@lists.opendaylight.org
 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org]
 On Behalf Of Michael Vorburger
Sent: Monday, May 14, 2018 10:35 PM
To: Luis Gomez >
Cc: 
integration-...@lists.opendaylight.org;
 genius-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [genius-dev] Autorelease build failing while 
adding dependency on genius-srm from openflowplugin

On Mon, May 14, 2018 at 6:59 PM, Luis Gomez 
> wrote:

afaik we do not allow cycles between projects so this code may require new 
project (if this has different scope than original) or new repo to resolve the 
conflict.

Can you tell us more about the "new repo" option? If we could have a 2nd repo, 
which from a governance perspective is part of the existing genius project, to 
host the code that is currently in genius/tools and genius/srm, and build that 
before openflowplugin, and then openflowplugin and then after that the "main" 
genius, then that is probably a good solution to this problem.

How would we get that?
On May 14, 2018, at 8:05 AM, Michael Vorburger 
> wrote:

On Mon, May 14, 2018 at 1:52 PM, D Arunprakash 
> wrote:
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 

Re: [openflowplugin-dev] [release] openflowplugin build failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

[Faseela K]

This job is stuck at the same place even now! ☹

From: Faseela K
Sent: Wednesday, May 16, 2018 12:33 PM
To: 'Anil Vishnoi' <vishnoia...@gmail.com>; 'Michael Vorburger' 
<vorbur...@redhat.com>
Cc: '<t...@lists.opendaylight.org>' <t...@lists.opendaylight.org>; 
'openflowplugin-dev' <openflowplugin-dev@lists.opendaylight.org>; 'release 
(rele...@lists.opendaylight.org)' <rele...@lists.opendaylight.org>
Subject: RE: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Multi patch job is stuck for quite some time at genius DataBrokerFailureTest 
now.

https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/47/console

03:26:41 ---
03:26:41  T E S T S
03:26:41 ---
03:26:42 Running 
org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoCloseableModuleTest
03:26:43 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.288 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoCloseableModuleTest
03:26:43 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestableListenerTest
03:26:44 Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.643 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestableListenerTest
03:26:44 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoordinatorEventsWaiterTest
03:26:47 Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.516 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoordinatorEventsWaiterTest
03:26:47 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.DataBrokerFailuresTest
[https://jenkins.opendaylight.org/releng/static/f332478f/images/spinner.gif]


Thanks,
Faseela

From: Faseela K
Sent: Wednesday, May 16, 2018 10:55 AM
To: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>; Michael 
Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: <t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>> 
<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 release 
(rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>) 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subject: RE: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Thanks Anil..
I am monitoring the output to see if genius patch builds fine, else will look 
into the failures!

Thanks,
Faseela

From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Anil 
Vishnoi
Sent: Wednesday, May 16, 2018 10:53 AM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: <t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>> 
<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 release 
(rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>) 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subject: Re: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Build #47 successfully passes for OFP, so i think OFP is good now.

On Tue, May 15, 2018 at 9:47 AM, Anil Vishnoi 
<vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> wrote:
Working on it.

On Tue, May 15, 2018 at 1:54 AM, Michael Vorburger 
<vorbur...@redhat.com<mailto:vorbur...@redhat.com>> wrote:
Anil,

On Mon, May 14, 2018 at 11:14 PM, Anil Vishnoi 
<vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> wrote:
Hi Michael,

I already pushed the changes a while back  and topic is already set to 
binding-tlc-rpc.

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

as per 
https://lists.opendaylight.org/pipermail/openflowplugin-dev/2018-May/008287.html,
 apparently that is NOK?

FYI I'm currently running 
https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/42/,
 but I guess it will fail with the same.

You can re-run a multipatch job yourself and put the link to it into the "ODL 
Last FULL Build:" field on https://jira.opendaylight.org/browse/TSC-99.

Will you have a look and let us know when that's resolved?

On Wed, May 9, 2018 at 7:22 AM, Mich

Re: [openflowplugin-dev] [release] openflowplugin build failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

[Faseela K]

Multi patch job is stuck for quite some time at genius DataBrokerFailureTest 
now.

https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/47/console

03:26:41 ---
03:26:41  T E S T S
03:26:41 ---
03:26:42 Running 
org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoCloseableModuleTest
03:26:43 Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.288 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.infra.tests.AutoCloseableModuleTest
03:26:43 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestableListenerTest
03:26:44 Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.643 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.tests.AbstractTestableListenerTest
03:26:44 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoordinatorEventsWaiterTest
03:26:47 Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.516 
sec - in 
org.opendaylight.genius.datastoreutils.testutils.tests.TestableJobCoordinatorEventsWaiterTest
03:26:47 Running 
org.opendaylight.genius.datastoreutils.testutils.tests.DataBrokerFailuresTest
[https://jenkins.opendaylight.org/releng/static/f332478f/images/spinner.gif]


Thanks,
Faseela

From: Faseela K
Sent: Wednesday, May 16, 2018 10:55 AM
To: Anil Vishnoi <vishnoia...@gmail.com>; Michael Vorburger 
<vorbur...@redhat.com>
Cc: <t...@lists.opendaylight.org> <t...@lists.opendaylight.org>; 
openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; release 
(rele...@lists.opendaylight.org) <rele...@lists.opendaylight.org>
Subject: RE: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Thanks Anil..
I am monitoring the output to see if genius patch builds fine, else will look 
into the failures!

Thanks,
Faseela

From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Anil 
Vishnoi
Sent: Wednesday, May 16, 2018 10:53 AM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: <t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>> 
<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 release 
(rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>) 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subject: Re: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Build #47 successfully passes for OFP, so i think OFP is good now.

On Tue, May 15, 2018 at 9:47 AM, Anil Vishnoi 
<vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> wrote:
Working on it.

On Tue, May 15, 2018 at 1:54 AM, Michael Vorburger 
<vorbur...@redhat.com<mailto:vorbur...@redhat.com>> wrote:
Anil,

On Mon, May 14, 2018 at 11:14 PM, Anil Vishnoi 
<vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> wrote:
Hi Michael,

I already pushed the changes a while back  and topic is already set to 
binding-tlc-rpc.

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

as per 
https://lists.opendaylight.org/pipermail/openflowplugin-dev/2018-May/008287.html,
 apparently that is NOK?

FYI I'm currently running 
https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/42/,
 but I guess it will fail with the same.

You can re-run a multipatch job yourself and put the link to it into the "ODL 
Last FULL Build:" field on https://jira.opendaylight.org/browse/TSC-99.

Will you have a look and let us know when that's resolved?

On Wed, May 9, 2018 at 7:22 AM, Michael Vorburger 
<vorbur...@redhat.com<mailto:vorbur...@redhat.com>> wrote:
Dear maintainers of project openflowplugin,

While verifying the proposed cross-projects changes on managed 
topic:binding-tlc-rpc together, your project failed to build; please see 
https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/34/.

You can locally reproduce this via a `mvn -Pq clean install` of the changed 
artifacts from your dependencies, and then building your project with it:

https://git.opendaylight.org/gerrit/#/q/topic:binding-tlc-rpc

Please raise a similar change for your project which fixes this problem.  Then 
set its topic to 'binding-tlc-rpc', and reply to this email to ask for a new 
build on this managed topic.  If you don't hear from me anymore, then all is 
good; otherwise I will email this project mailing list again with a new email 
similar

Re: [openflowplugin-dev] [release] openflowplugin build failure in proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

[Faseela K]

Thanks Anil..
I am monitoring the output to see if genius patch builds fine, else will look 
into the failures!

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Anil 
Vishnoi
Sent: Wednesday, May 16, 2018 10:53 AM
To: Michael Vorburger 
Cc:  ; 
openflowplugin-dev ; release 
(rele...@lists.opendaylight.org) 
Subject: Re: [openflowplugin-dev] [release] openflowplugin build failure in 
proposed topic:binding-tlc-rpc ("Weather Item" TSC-99)

Build #47 successfully passes for OFP, so i think OFP is good now.

On Tue, May 15, 2018 at 9:47 AM, Anil Vishnoi 
> wrote:
Working on it.

On Tue, May 15, 2018 at 1:54 AM, Michael Vorburger 
> wrote:
Anil,

On Mon, May 14, 2018 at 11:14 PM, Anil Vishnoi 
> wrote:
Hi Michael,

I already pushed the changes a while back  and topic is already set to 
binding-tlc-rpc.

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

as per 
https://lists.opendaylight.org/pipermail/openflowplugin-dev/2018-May/008287.html,
 apparently that is NOK?

FYI I'm currently running 
https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/42/,
 but I guess it will fail with the same.

You can re-run a multipatch job yourself and put the link to it into the "ODL 
Last FULL Build:" field on https://jira.opendaylight.org/browse/TSC-99.

Will you have a look and let us know when that's resolved?

On Wed, May 9, 2018 at 7:22 AM, Michael Vorburger 
> wrote:
Dear maintainers of project openflowplugin,

While verifying the proposed cross-projects changes on managed 
topic:binding-tlc-rpc together, your project failed to build; please see 
https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/34/.

You can locally reproduce this via a `mvn -Pq clean install` of the changed 
artifacts from your dependencies, and then building your project with it:

https://git.opendaylight.org/gerrit/#/q/topic:binding-tlc-rpc

Please raise a similar change for your project which fixes this problem.  Then 
set its topic to 'binding-tlc-rpc', and reply to this email to ask for a new 
build on this managed topic.  If you don't hear from me anymore, then all is 
good; otherwise I will email this project mailing list again with a new email 
similar to this one.

If you would like to reach a human for any questions about this, please do not 
reply to this email, but instead read the JIRA issue 
https://jira.opendaylight.org//browse/TSC-99,
 and reach out to its Reporter in case of any doubt.

Yours sincerely,
The ODL Bot 


https://git.opendaylight.org/gerrit/#/q/topic:binding-tlc-rpc

https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/34/


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



--
Thanks
Anil




--
Thanks
Anil



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

[openflowplugin-dev] Running multipatch job for TSC-99

[Faseela K]

Hello,
  I am trying to run a multi-patch job for TSC-99 on my genius patch, using the 
keyword "multipatch-build:topic=binding-tlc-rpc"
  However it fails at openflowplugin as below :


https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/41/console

  @Luis Gomez : Is the format for running multi-patch 
correct, or any orders need to be specified?
Thanks,
Faseela
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [controller-dev] [release] Carbon SR4 - stable/carbon branch locked

[Faseela K]

Luis,
   If this is blocking others on carbon, we can revert it. Without this patch 
lldp functionality will be broken, but currently nobody is using the same 
upstream. But as you indicated, yes the same patch is available in all other 
higher  branches.
Thanks,
Faseela

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Luis Gomez
Sent: Thursday, April 26, 2018 10:41 AM
To: Thanh Ha 
Cc: d...@lists.opendaylight.org; opendaylight sfc 
; lacp-...@lists.opendaylight.org; 
openflowplugin-dev ; Ariel Adam 
; odl groupbasedpolicy dev 
; 
mdsal-...@lists.opendaylight.org; Release ; 
yangtools-dev ; netconf-dev 
; iotdm-...@lists.opendaylight.org; 
l2switch-...@lists.opendaylight.org; bier-...@lists.opendaylight.org; 
nic-...@lists.opendaylight.org; ocpplugin-...@lists.opendaylight.org; 
didm-...@lists.opendaylight.org; controller-dev 
; unimgr-...@lists.opendaylight.org
Subject: Re: [controller-dev] [openflowplugin-dev] [release] Carbon SR4 - 
stable/carbon branch locked

After some investigation, this patch in genius seems to be the one introducing 
the regression in carbon:

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

However if nobody sees any issue I think we can ignore the failure as it is not 
happening in any other branch where the above patch is already merged.

BR/Luis



On Apr 25, 2018, at 9:15 AM, Luis Gomez 
> wrote:

FYI I have just  detected a recent feature conflict in Carbon through this job:

https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1node-flow-services-all-carbon/

It seems like when all compatible features are are loaded, openflowplugin does 
not recognize nicira extensions:

2018-04-19 00:19:00,446 | WARN  | ntLoopGroup-13-5 | MatchSerializer
  | 317 - org.opendaylight.openflowplugin.impl - 0.4.4.Carbon | Serializer 
for match entry interface 
org.opendaylight.yang.gen.v1.urn.opendaylight.openflowplugin.extension.general.rev140714.general.extension.grouping.Extension
 for version 4 not found.


Does anyone using nicira extensions have also noticed any regression in the 
last week?

BR/Luis




On Apr 25, 2018, at 6:17 AM, Thanh Ha 
> wrote:

On Sun, Apr 22, 2018 at 8:18 PM, Anil Belur 
> wrote:
On Mon, Apr 23, 2018 at 9:26 AM, Anil Belur 
> wrote:
Hi everyone,

We have locked the branch (stable/carbon) for Carbon SR4 release and started RC 
build #583.

Please open blocking bugs for any issues that need to be resolved for Carbon 
SR4.

Regards,
Anil

[1.] 
https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-carbon/583/


Hello everyone:

We have not had any changes since build #581 and the build has completed along 
with the integration-test results in [2.], therefore the build #581 can be 
considered as the release candidate.

Please help review and sign off on these failures [2.] as soon as possible to 
allow us to formally release Carbon SR4.

Thanks,
Anil

[1.] 
https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#SR4_Download
[2.] 
https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=558129117

 Hi Everyone,

Just a reminder that we have a Carbon-SR4 release candidate that still needs 
sign-offs. The following projects still need signoffs as of right now:

* Bier
* Controller
* DIDM
* GroupBasedPolicy
* iotdm
* l2switch
* lacp
* mdsal
* netconf
* nic
* ocpplugin
* openflowplugin
* sfc
* unimgr
* yangtools

Thanks,
Thanh

___
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] [release] [integration-dev] IMPORTANT: Build breakage in openflowplugin due IP address NoZone changes

[Faseela K]

With the revert, CSITs are running fine for genius and netvirt.

Thanks,
Faseela

From: Abhijit Kumbhare [mailto:abhijitk...@gmail.com]
Sent: Monday, April 23, 2018 8:47 PM
To: Faseela K <faseel...@ericsson.com>
Cc: Luis Gomez <ece...@gmail.com>; Release <rele...@lists.opendaylight.org>; 
integration-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [release] [integration-dev] [openflowplugin-dev] IMPORTANT: Build 
breakage in openflowplugin due IP address NoZone changes

So I assume this topic is closed - and no need to have today's TWS session on 
this?

On Sun, Apr 22, 2018 at 8:52 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
From the subsequent mails from Robert and Anil, there is a proposal that the 
change will be enhanced to fix equals() to be backward compatible. +1 to that.

Thanks,
Faseela

From: Abhijit Kumbhare 
[mailto:abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>]
Sent: Monday, April 23, 2018 3:05 AM
To: Luis Gomez <ece...@gmail.com<mailto:ece...@gmail.com>>
Cc: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Release 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [release] [integration-dev] [openflowplugin-dev] IMPORTANT: Build 
breakage in openflowplugin due IP address NoZone changes

+100. Couldn’t have said it better. Folks - please confirm the answers to 
Luis’s questions.

On Sun, Apr 22, 2018 at 1:16 PM Luis Gomez 
<ece...@gmail.com<mailto:ece...@gmail.com>> wrote:
I hope as a community we can learn some lessons from this breakage:

- Upstream projects: please do not push changes breaking or changing API 
behavior without notice or weather item. If the impact is unintentional please 
revert quick to minimize downtime and confusion.
- Downstream projects: please attend the TSC meetings (at least the Managed 
ones), so when a decision is made impacting you, you can agree or object but 
not complaint later.

Now that patch has been reverted and weather is in place:

- Is anybody still interested in driving this change?
- If so any objection from any downstream project?

BR/Luis


On Apr 22, 2018, at 11:04 AM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:

Here are the revert patches in lispflowmapping and bgpcep.

https://git.opendaylight.org/gerrit/#/c/71187/
https://git.opendaylight.org/gerrit/#/c/71193/

However, FYI that Anil has removed his -1 on ofp patch, and a weather is 
already in place. Also genius and netvirt CSITs are passing with the ovsdb 
patch. In case we decide to merge those patches in, the above ones can be 
abandoned.


Thanks,
Faseela

From: 
release-boun...@lists.opendaylight.org<mailto:release-boun...@lists.opendaylight.org>
 [mailto:release-boun...@lists.opendaylight.org]On Behalf Of Tom Pantelis
Sent: Sunday, April 22, 2018 4:37 AM
To: Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>
Cc: 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>;
 Release <rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subject: Re: [release] [openflowplugin-dev] IMPORTANT: Build breakage in 
openflowplugin due IP address NoZone changes



On Sat, Apr 21, 2018 at 6:22 PM, Sam Hague 
<sha...@redhat.com<mailto:sha...@redhat.com>> wrote:
Well, maybe we can keep the change.. I ran ovsdb [1] and netvirt csit [2] using 
the ovsdb patch Vishal had for the issue and they both look to have passed. 
NetVirt relies on ofp, ovsdb and genius so that seems to show things work. I 
ran this in the last couple hours using the ovsdb distro from yesterday which 
should have been before Tom reverted the patch. If someone could verify my 
comment that the artifacts used in the CSIT run truly do have the changes, then 
maybe we can keep this change.

That's good that it passed. But folks were asking to revert so that's what I 
did. If someone wants to "unrevert" it and drive that and ensure there's no 
other breakages, that's fine.



Thanks, Sam

[1] 
https://jenkins.opendaylight.org/releng/job/ovsdb-patch-test-core-fluorine/16/

[2] 
https://jenkins.opendaylight.org/releng/job/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/236

On Sat, Apr 21, 2018 at 7:13 AM, Abhijit Kumbhare 
<abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>&g

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

[Faseela K]

From the subsequent mails from Robert and Anil, there is a proposal that the 
change will be enhanced to fix equals() to be backward compatible. +1 to that.

Thanks,
Faseela

From: Abhijit Kumbhare [mailto:abhijitk...@gmail.com]
Sent: Monday, April 23, 2018 3:05 AM
To: Luis Gomez <ece...@gmail.com>
Cc: Faseela K <faseel...@ericsson.com>; Release 
<rele...@lists.opendaylight.org>; integration-...@lists.opendaylight.org; 
mdsal-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org
Subject: Re: [release] [integration-dev] [openflowplugin-dev] IMPORTANT: Build 
breakage in openflowplugin due IP address NoZone changes

+100. Couldn’t have said it better. Folks - please confirm the answers to 
Luis’s questions.

On Sun, Apr 22, 2018 at 1:16 PM Luis Gomez 
<ece...@gmail.com<mailto:ece...@gmail.com>> wrote:
I hope as a community we can learn some lessons from this breakage:

- Upstream projects: please do not push changes breaking or changing API 
behavior without notice or weather item. If the impact is unintentional please 
revert quick to minimize downtime and confusion.
- Downstream projects: please attend the TSC meetings (at least the Managed 
ones), so when a decision is made impacting you, you can agree or object but 
not complaint later.

Now that patch has been reverted and weather is in place:

- Is anybody still interested in driving this change?
- If so any objection from any downstream project?

BR/Luis


On Apr 22, 2018, at 11:04 AM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:

Here are the revert patches in lispflowmapping and bgpcep.

https://git.opendaylight.org/gerrit/#/c/71187/
https://git.opendaylight.org/gerrit/#/c/71193/

However, FYI that Anil has removed his -1 on ofp patch, and a weather is 
already in place. Also genius and netvirt CSITs are passing with the ovsdb 
patch. In case we decide to merge those patches in, the above ones can be 
abandoned.


Thanks,
Faseela

From: 
release-boun...@lists.opendaylight.org<mailto:release-boun...@lists.opendaylight.org>
 [mailto:release-boun...@lists.opendaylight.org]On Behalf Of Tom Pantelis
Sent: Sunday, April 22, 2018 4:37 AM
To: Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>
Cc: 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>;
 Release <rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>
Subject: Re: [release] [openflowplugin-dev] IMPORTANT: Build breakage in 
openflowplugin due IP address NoZone changes



On Sat, Apr 21, 2018 at 6:22 PM, Sam Hague 
<sha...@redhat.com<mailto:sha...@redhat.com>> wrote:
Well, maybe we can keep the change.. I ran ovsdb [1] and netvirt csit [2] using 
the ovsdb patch Vishal had for the issue and they both look to have passed. 
NetVirt relies on ofp, ovsdb and genius so that seems to show things work. I 
ran this in the last couple hours using the ovsdb distro from yesterday which 
should have been before Tom reverted the patch. If someone could verify my 
comment that the artifacts used in the CSIT run truly do have the changes, then 
maybe we can keep this change.

That's good that it passed. But folks were asking to revert so that's what I 
did. If someone wants to "unrevert" it and drive that and ensure there's no 
other breakages, that's fine.



Thanks, Sam

[1] 
https://jenkins.opendaylight.org/releng/job/ovsdb-patch-test-core-fluorine/16/

[2] 
https://jenkins.opendaylight.org/releng/job/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/236

On Sat, Apr 21, 2018 at 7:13 AM, Abhijit Kumbhare 
<abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>> wrote:
Thanks Robert.

On Sat, Apr 21, 2018 at 5:27 AM, Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> 
wrote:
On 21/04/18 01:49, Robert Varga wrote:
>> The weather process
>> needed to have been followed - with the possibility for downstream
>> projects to not accept the change for legitimate reasons. Please do so
>> in the future.
>>
>> The most ideal solution as suggested by Luis below & initially agreed by
>> Tom would have been to back out the change, discuss it completely (in a
>> the TWS call) and go ahead with the decision after the TWS call. As it
>> stands, and pointed by Tom, backing out the change looks to be a
>> daunting task. Since that is the case, let us do the following:
>> 0) Unblock the projects by whatever means - whether it is projects
>> merging the changes to accommodate the original patch or reverting
>> 1) Robert, please create the weather report with the existing change
> Sorry for the delay, today has been exceptionally busy, I wil

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

[Faseela K]

Here are the revert patches in lispflowmapping and bgpcep.

https://git.opendaylight.org/gerrit/#/c/71187/
https://git.opendaylight.org/gerrit/#/c/71193/

However, FYI that Anil has removed his -1 on ofp patch, and a weather is 
already in place. Also genius and netvirt CSITs are passing with the ovsdb 
patch. In case we decide to merge those patches in, the above ones can be 
abandoned.


Thanks,
Faseela

From: release-boun...@lists.opendaylight.org 
[mailto:release-boun...@lists.opendaylight.org] On Behalf Of Tom Pantelis
Sent: Sunday, April 22, 2018 4:37 AM
To: Sam Hague 
Cc: integration-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org; Release 

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



On Sat, Apr 21, 2018 at 6:22 PM, Sam Hague 
> wrote:
Well, maybe we can keep the change.. I ran ovsdb [1] and netvirt csit [2] using 
the ovsdb patch Vishal had for the issue and they both look to have passed. 
NetVirt relies on ofp, ovsdb and genius so that seems to show things work. I 
ran this in the last couple hours using the ovsdb distro from yesterday which 
should have been before Tom reverted the patch. If someone could verify my 
comment that the artifacts used in the CSIT run truly do have the changes, then 
maybe we can keep this change.

That's good that it passed. But folks were asking to revert so that's what I 
did. If someone wants to "unrevert" it and drive that and ensure there's no 
other breakages, that's fine.



Thanks, Sam

[1] 
https://jenkins.opendaylight.org/releng/job/ovsdb-patch-test-core-fluorine/16/

[2] 
https://jenkins.opendaylight.org/releng/job/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/236

On Sat, Apr 21, 2018 at 7:13 AM, Abhijit Kumbhare 
> wrote:
Thanks Robert.

On Sat, Apr 21, 2018 at 5:27 AM, Robert Varga > 
wrote:
On 21/04/18 01:49, Robert Varga wrote:
>> The weather process
>> needed to have been followed - with the possibility for downstream
>> projects to not accept the change for legitimate reasons. Please do so
>> in the future.
>>
>> The most ideal solution as suggested by Luis below & initially agreed by
>> Tom would have been to back out the change, discuss it completely (in a
>> the TWS call) and go ahead with the decision after the TWS call. As it
>> stands, and pointed by Tom, backing out the change looks to be a
>> daunting task. Since that is the case, let us do the following:
>> 0) Unblock the projects by whatever means - whether it is projects
>> merging the changes to accommodate the original patch or reverting
>> 1) Robert, please create the weather report with the existing change
> Sorry for the delay, today has been exceptionally busy, I will file a
> weather item tomorrow.
>

https://jira.opendaylight.org/browse/TSC-96

Regards,
Robert


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


___
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] [integration-dev] [mdsal-dev] IMPORTANT: Build breakage in openflowplugin due IP address NoZone changes

[Faseela K]

I don’t have a problem with both the approaches, just that we need a way 
forward.


  1.  Revert mdsal patch, along with lisp and other patches which got merged to 
adapt to the same.

OR

  1.  Merge ofp and ovsdb patches to see if we have any more issues in genius 
and netvirt CSIT.

But since Anil has raised a concern on adapting the change in ofp, that 
discussion needs to be closed.

Else, mdsal should provide a backward compatible change, so that users are free 
to choose what to use.
If this discussion will take more time, I am not seeing any option 
other than 1.

Thanks,
Faseela

From: Abhijit Kumbhare [mailto:abhijitk...@gmail.com]
Sent: Saturday, April 21, 2018 9:24 AM
To: Vishal Thapar <vtha...@redhat.com>
Cc: Faseela K <faseel...@ericsson.com>; Sam Hague <sha...@redhat.com>; 
openflowplugin-dev@lists.opendaylight.org; tsc <t...@lists.opendaylight.org>; 
mdsal-...@lists.opendaylight.org; Release <rele...@lists.opendaylight.org>; 
Robert Varga <n...@hq.sk>; integration-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [integration-dev] [mdsal-dev] IMPORTANT: 
Build breakage in openflowplugin due IP address NoZone changes

As I said earlier - the fastest thing would be for Robert & others to back out 
all the no zone changes from MD-SAL & other projects and unblock everyone. And 
then have the decision whether to have the change (after the weather report) => 
if +1 from the respective parties (PTLs of dependent/affected projects like 
you, Faseela, etc.) then add the changes back to MD-SAL & all the projects if 
thumbs up from PTLs.

Is there any problem with the above approach?

On Fri, Apr 20, 2018 at 8:45 PM, Vishal Thapar 
<vtha...@redhat.com<mailto:vtha...@redhat.com>> wrote:
Hi Sam, Faseela,

Yes, we can't rule out similar issues in Genius/Netvirt, thought a good thing 
would be to check for use of the API. OVSDB patch should resolve the Genius 
issue for now. Why don't we merge it so we can test Genius CSIT. If needed, can 
always be reverted later.

Regards,
Vishal.

On Sat, Apr 21, 2018 at 8:59 AM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
I don’t know what the decision is yet.
We are talking about outstanding patches in ofp and ovsdb. Ofp patch still has 
Anil’s -1.
And we are saying TSC decision is to merge these pending patches.
We will be broken till we get a conclusion on this, we do have a lot of pending 
patches in genius just awaiting CSIT results to get merged. And we are all 
blocked.

Thanks,
Faseela

From: Sam Hague [mailto:sha...@redhat.com<mailto:sha...@redhat.com>]
Sent: Saturday, April 21, 2018 7:10 AM
To: Abhijit Kumbhare <abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>>
Cc: Robert Varga <n...@hq.sk<mailto:n...@hq.sk>>; Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; tsc 
<t...@lists.opendaylight.org<mailto:t...@lists.opendaylight.org>>; 
mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; 
Release 
<rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>>; 
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>;
 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [integration-dev] [mdsal-dev] [openflowplugin-dev] IMPORTANT: 
Build breakage in openflowplugin due IP address NoZone changes


On Fri, Apr 20, 2018, 9:13 PM Abhijit Kumbhare 
<abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>> wrote:
Thanks Robert (previous email responses). As I understand OVSDB and Genius are 
having issues making their builds work after integrating the no-zone patches. 
Hence revert first makes the most sense for the fastest unblocking everyone.
Do we know if there is further collateral damage down the line? Meeting netvirt 
csit is broken from the ovsdb issue so we haven't verified if it also suffers.

On Fri, Apr 20, 2018 at 5:02 PM, Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> 
wrote:
On 20/04/18 18:31, Abhijit Kumbhare wrote:
> Agree - it will be best to revert in my opinion & then figure out the
> way forward. Especially since its breaking downstream that will take
> longer. Can you guys revert it Robert or Tom?

Hello Abhijit,

The way I am reading the situation is that we have two outstanding
patches to bring us over the hump -- OFP and OVSDB. Reverting means
reverting also in bgpcep and lispflowmapping (IIRC) -- is that factored
in your appraisal of the situation?

Regards,
Robert

___
integration-dev mailing list
integration-...@lists.opendaylight.org<mailto:integration-...@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/integration-dev

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

[Faseela K]

I don’t know what the decision is yet.
We are talking about outstanding patches in ofp and ovsdb. Ofp patch still has 
Anil’s -1.
And we are saying TSC decision is to merge these pending patches.
We will be broken till we get a conclusion on this, we do have a lot of pending 
patches in genius just awaiting CSIT results to get merged. And we are all 
blocked.

Thanks,
Faseela

From: Sam Hague [mailto:sha...@redhat.com]
Sent: Saturday, April 21, 2018 7:10 AM
To: Abhijit Kumbhare <abhijitk...@gmail.com>
Cc: Robert Varga <n...@hq.sk>; Faseela K <faseel...@ericsson.com>; tsc 
<t...@lists.opendaylight.org>; mdsal-...@lists.opendaylight.org; Release 
<rele...@lists.opendaylight.org>; integration-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org
Subject: Re: [integration-dev] [mdsal-dev] [openflowplugin-dev] IMPORTANT: 
Build breakage in openflowplugin due IP address NoZone changes


On Fri, Apr 20, 2018, 9:13 PM Abhijit Kumbhare 
<abhijitk...@gmail.com<mailto:abhijitk...@gmail.com>> wrote:
Thanks Robert (previous email responses). As I understand OVSDB and Genius are 
having issues making their builds work after integrating the no-zone patches. 
Hence revert first makes the most sense for the fastest unblocking everyone.
Do we know if there is further collateral damage down the line? Meeting netvirt 
csit is broken from the ovsdb issue so we haven't verified if it also suffers.

On Fri, Apr 20, 2018 at 5:02 PM, Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> 
wrote:
On 20/04/18 18:31, Abhijit Kumbhare wrote:
> Agree - it will be best to revert in my opinion & then figure out the
> way forward. Especially since its breaking downstream that will take
> longer. Can you guys revert it Robert or Tom?

Hello Abhijit,

The way I am reading the situation is that we have two outstanding
patches to bring us over the hump -- OFP and OVSDB. Reverting means
reverting also in bgpcep and lispflowmapping (IIRC) -- is that factored
in your appraisal of the situation?

Regards,
Robert

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

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

[Faseela K]

We see issues in ovsdb plugin also now.
If functionalities are broken due to the patch, it is taking a lot of time for 
us also to debug and figure out where and all it is causing breakages.

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Luis 
Gomez
Sent: Friday, April 20, 2018 8:36 PM
To: Michael Vorburger 
Cc: openflowplugin-dev@lists.opendaylight.org; tsc 
; mdsal-...@lists.opendaylight.org; Release 
; integration-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [mdsal-dev] IMPORTANT: Build breakage in 
openflowplugin due IP address NoZone changes


On Apr 20, 2018, at 3:22 AM, Michael Vorburger 
> wrote:

On Thu, Apr 19, 2018 at 9:52 PM, Luis Gomez 
> wrote:
FYI I just opened a grievance to remind what we did today is exceptional and to 
be avoided in future:

https://jira.opendaylight.org/browse/TSC-92

I've commented in TSC-92 arguing that I'm struggling to understand how "it 
stands, and pointed by Tom, backing out the change looks to be a daunting task"…

Please ask Tom P and Robert, both said during TSC call it was lot of work to 
revert, in addition nobody except Anil saw any problem wth the patch so that 
was the other reason it went through.


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


BR/Luis

On Apr 19, 2018, at 11:44 AM, Abhijit Kumbhare 
> wrote:

Added the TSC.

On Thu, Apr 19, 2018 at 11:41 AM, Abhijit Kumbhare 
> wrote:
Robert & Tom,

Regardless of the merits of this particular change, I agree with Vishal & Luis 
that this is a failure of communication. The weather process needed to have 
been followed - with the possibility for downstream projects to not accept the 
change for legitimate reasons. Please do so in the future.

The most ideal solution as suggested by Luis below & initially agreed by Tom 
would have been to back out the change, discuss it completely (in a the TWS 
call) and go ahead with the decision after the TWS call. As it stands, and 
pointed by Tom, backing out the change looks to be a daunting task. Since that 
is the case, let us do the following:
0) Unblock the projects by whatever means - whether it is projects merging the 
changes to accommodate the original patch or reverting
1) Robert, please create the weather report with the existing change
2)  in the meantime people can chime in on the thread and try to resolve it
3) we WILL continue the discussion on the Monday TWS if this is not resolved by 
Monday. Casey has this meeting scheduled in any case.

Thanks,
Abhijit

On Thu, Apr 19, 2018 at 10:46 AM, Luis Gomez 
> wrote:

On Apr 19, 2018, at 7:16 AM, Tom Pantelis 
> wrote:



On Thu, Apr 19, 2018 at 9:14 AM, Vishal Thapar 
> wrote:
Hi Robert,

Could you please take a look at tell what I need to fix this breakage? I am 
still not sure why is such a basic code breaking like this.


Perhaps we should just revert the mdsal patch until this can get sorted out 
downstream - maybe discuss on the TSC call today .

+1, without knowing the technical details of the change, I think we are missing 
something fundamental in the upstream-downstream communication: in general for 
any valid change coming from upstream breaking downstream we need a weather 
report including explanation why the change is required and some pointers on 
how to fix the potential failures. This gives a chance for downstream projects 
to evaluate and accept the change as well as to prepare the required patches to 
minimize the impact. If the breakage was unintentional or unexpected (no 
weather fired), I think the right thing to do is to revert and start over 
writing the weather report.




Regards,
Vishal.



___
mdsal-dev mailing list
mdsal-...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/mdsal-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


___
mdsal-dev mailing list

Re: [openflowplugin-dev] How to match on VLAN

[Faseela K]

Brady,
  This is correct.
  We use this approach in genius as well as netvirt, to program table 0 flows.
  If you do setVlanIdPresent(false) with vlanId=0, you can see flow like below :
  cookie=0x800, duration=155.130s, table=0, n_packets=236, 
n_bytes=24384, priority=4,in_port=4,vlan_tci=0x/0x1fff 
actions=write_metadata:0x700/0xff01,goto_table:17

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Brady 
Johnson
Sent: Sunday, April 15, 2018 6:49 AM
To: Ryan Goulding 
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] How to match on VLAN

I just figured it out. I was looking through the Openflow Plugin code, and 
found in this file:

openflowplugin/src/main/java/org/opendaylight/openflowplugin/openflow/md/core/sal/convertor/flow/FlowConvertor.java

This piece of code:

final VlanId zeroVlan = new VlanId(0);
VlanMatchBuilder vlanMatchBuilder = new VlanMatchBuilder();
VlanIdBuilder vlanIdBuilder = new VlanIdBuilder();
vlanIdBuilder.setVlanIdPresent(false);
vlanIdBuilder.setVlanId(zeroVlan);
vlanMatchBuilder.setVlanId(vlanIdBuilder.build());

VLAN_MATCH_FALSE = vlanMatchBuilder.build();

VlanMatchBuilder vlanMatchBuilder2 = new VlanMatchBuilder();
VlanIdBuilder vlanIdBuilder2 = new VlanIdBuilder();
vlanIdBuilder2.setVlanIdPresent(true);
vlanIdBuilder2.setVlanId(zeroVlan);
vlanMatchBuilder2.setVlanId(vlanIdBuilder2.build());

VLAN_MATCH_TRUE = vlanMatchBuilder2.build();

So, I tried the following match:

final VlanId vlanId = new VlanId(vlan);
VlanMatchBuilder vlanMatchBuilder = new VlanMatchBuilder();
VlanIdBuilder vlanIdBuilder = new VlanIdBuilder();
vlanIdBuilder.setVlanIdPresent(true);
vlanIdBuilder.setVlanId(vlanId);
vlanMatchBuilder.setVlanId(vlanIdBuilder.build());

match.setVlanMatch(vlanMatchBuilder.build());

And now I can add SetVlanId and StripVlan Actions. Im hoping that matching on 
VlanId=0 is basically matching on any VlanId.

Here are the 2 flows that I get:

 cookie=0xba5eba11, duration=4.454s, table=30, n_packets=0, n_bytes=0, 
priority=500,ip,vlan_tci=0x1000/0x1000,nw_dst=192.168.1.0/24
 actions=load:0x5ad2a7aa->NXM_NX_REG1[],set_field:4196->vlan_vid,goto_table:40
 cookie=0xba5eba11, duration=4.453s, table=90, n_packets=0, n_bytes=0, 
priority=700,vlan_tci=0x1000/0x1000 actions=pop_vlan,output:8

Thanks,

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 Sat, Apr 14, 2018 at 7:38 PM, Brady Johnson 
> wrote:
That's right Ryan, this is Nitrogen-SR2.

If nobody has experienced this, can somebody please point me to where the 
Openflow Plugin VLAN validation code is? That is, there must be a Config Data 
Store listener that validates the flows, and if there is something it doesnt 
like, it wont write the flows to the Operational data store. I would like to 
see what it considers as valid/invalid for flows with setVlanId and popVlan 
actions.

Regards,

Brady Johnson
bjohn...@inocybe.ca


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

Re: [openflowplugin-dev] How to match on VLAN

[Faseela K]

Brady,
  Take a look at MatchVlanBuilder.java in genius. We set a Boolean field to 
indicate whether vlan id is present or not.

protected void populateBuilder(VlanMatchBuilder builder) {
builder.setVlanId(new VlanIdBuilder()
.setVlanId(new VlanId(vlanId))
.setVlanIdPresent(vlanId != 0)
.build());
}

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Ryan 
Goulding
Sent: Sunday, April 15, 2018 5:32 AM
To: M. Ranganathan 
Cc: Brady Johnson ; openflowplugin-dev 

Subject: Re: [openflowplugin-dev] How to match on VLAN

IIRC this is based off Nitrogen-SR2, so shouldn't be prone to the issues listed 
there.

Thanks!

Regards,

Ryan Goulding

On Sat, Apr 14, 2018 at 6:52 PM, M. Ranganathan 
> wrote:


Not sure if this would help ( I was trying something a little different than 
you are ) but I had some issues creating set Vlan flows in Carbon  
https://stackoverflow.com/questions/47610513/how-to-create-a-set-vlan-flow
I had much better luck with Nitrogen


Ranga

On Fri, Apr 13, 2018 at 5:42 PM, Brady Johnson 
> wrote:

Hello,

Im trying to write flows to pop-vlan or just simply set the vlan-id, but the 
flows arent being written to operational, nor the bridge. I tried doing an 
etherType match on VLAN (0x8100) but that doesnt help.

The 2 use cases I have are for flows that ingress the bridge with VLAN already 
set are:

1) if VLAN present (could be lots of different vlan IDs), pop it.
2) if VLAN present set the VLAN id to a different one.

Ive tried flows for both of these cases, and neither are written to 
Operational. Ideally there should be an 802.1Q TPID (Tag protocol ID) match 
field, where you could match on 0x8100, but I couldnt find anything like this.

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]



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



--
M. Ranganathan

___
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] Convert a Flow object into a command line string

[Faseela K]

I think it was not merged.
But you can see the patch here :

https://git.opendaylight.org/gerrit/#/c/63248/3/vpnservice/stfw/shell/src/main/java/org/opendaylight/netvirt/stfw/shell/DumpSwitch.java

Thanks,
Faseela

From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela K
Sent: Friday, April 13, 2018 6:59 AM
To: Michael Vorburger <vorbur...@redhat.com>; Xingjun Chu 
<xingjun@huawei.com>; Vishal Thapar <vishal.tha...@ericsson.com>
Cc: odl netvirt dev <netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org; Suja T <suj...@ericsson.com>; 
openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [netvirt-dev] [openflowplugin-dev] Convert a Flow object into a 
command line string

We had a scale test framework, which Vishal worked on upstreaming.
The framework, had a dump-flow utility in ODL, where it parses config/inventory 
and prints in “ovs-ofctl dump-flows” format.
@vishal : were those changes merged?

Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Friday, April 13, 2018 12:06 AM
To: Xingjun Chu <xingjun@huawei.com<mailto:xingjun@huawei.com>>
Cc: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 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>>;
 odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>;
 genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] Convert a Flow object into a command line 
string

On Thu, Apr 12, 2018 at 8:02 PM, Xingjun Chu 
<xingjun@huawei.com<mailto:xingjun@huawei.com>> wrote:

Hi,

I am wondering if there is such tool available to convert a Flow java Object 
into a for example  ovs-ofctl command line command?

not that I know of, but it could be a cool idea if you would like to contribute 
the code with a helper doing this.

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

Thanks
Xingjun

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org<mailto: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] Convert a Flow object into a command line string

[Faseela K]

We had a scale test framework, which Vishal worked on upstreaming.
The framework, had a dump-flow utility in ODL, where it parses config/inventory 
and prints in “ovs-ofctl dump-flows” format.
@vishal : were those changes merged?

Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Friday, April 13, 2018 12:06 AM
To: Xingjun Chu <xingjun@huawei.com>
Cc: Faseela K <faseel...@ericsson.com>; D Arunprakash 
<d.arunprak...@ericsson.com>; Suja T <suj...@ericsson.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>; odl netvirt dev 
<netvirt-...@lists.opendaylight.org>; genius-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] Convert a Flow object into a command line 
string

On Thu, Apr 12, 2018 at 8:02 PM, Xingjun Chu 
<xingjun@huawei.com<mailto:xingjun@huawei.com>> wrote:

Hi,

I am wondering if there is such tool available to convert a Flow java Object 
into a for example  ovs-ofctl command line command?

not that I know of, but it could be a cool idea if you would like to contribute 
the code with a helper doing this.

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

Thanks
Xingjun

___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org<mailto: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

[Faseela K]

Thanks Arun.
CSIT on Genius patch is passing now.
  https://git.opendaylight.org/gerrit/#/c/69527/

Thanks,
Faseela

From: D Arunprakash
Sent: Tuesday, April 10, 2018 4:55 PM
To: Faseela K <faseel...@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

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<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

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

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

[Faseela K]

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>; 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 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' 
<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-...@

Re: [openflowplugin-dev] [genius-dev] Move datastoreutils and other infra utilities outside mdsalutil?

[Faseela K]

Just an FYI.

We have added a new feature called “odl-genius-tools”, and have started 
migrating some of the datastore related utils to a new module called 
genius/tools [0].
This is just to make a light weight feature for use by applications who 
just need datastore related utils. Please use this new feature, so that you 
won’t have to add dependency on a heavier genius feature, just to use datastore 
related utilities.
Also make sure to use the utils from the new module for any of the upcoming 
patches, as the older ones are deprecated and the migration to the new utils in 
the existing code is in progress.

Thanks,
Faseela

[0] https://git.opendaylight.org/gerrit/#/c/69755/

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Thursday, March 15, 2018 3:14 PM
To: Faseela K <faseel...@ericsson.com>
Cc: genius-...@lists.opendaylight.org
Subject: Re: [genius-dev] Move datastoreutils and other infra utilities outside 
mdsalutil?

Hello,

On Thu, Mar 15, 2018 at 8:24 AM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi,
  Recently there was a requirement from openflowplugin, that they need an “srm” 
only feature.
  And they don’t want any dependency on mdsalutil as mdsalutil inturn depends 
on openflowplugin.
  Currently srm depends on mdsalutil, as some of the utilities(like 
AbstractClusteredSyncDataTreeChangeListener, FutureRpcResults etc) are within 
mdsautil-api.
  Was wondering whether we should have a separate module (“genius-infra” ??) so 
that we can separate out the openflow utilities and other infra utilities?

mdsalutil-api truly has grown into a bit of too much, and the package names in 
it are a mess, so I'm totally in favour of doing such a split. In addition to 
resolving your specific short term problem re. genius' SRM use by 
openflowplugin, I think by clearly separating and offering a few of the general 
purpose utilities which have grown in genius in a separate bundle and Karaf 
feature, we can perhaps make them more of interest to other projects than just 
genius itself and netvirt as well; I'm specifically thinking e.g. 
openflowplugin perhaps having an interest to later use some of them even 
directly, not indirectly via SRM, or e.g. for upcoming work in neutron.

The "scope" of this new bundle IMHO should include MD SAL DataBroker related 
utilities (which we cannot host in the only lower-level infrautils; where they 
should continue to go if appropriate), but without any YANG models (just 
because those are typically always already "higher-level functionalities" which 
should better be placed elsewhere). For example, a specific functionality such 
as SRM should remain in its own bundle, that's just fine, and lets us have good 
modularity boundaries. As such, I would expect this new bundle to only ever 
have dependencies to infrautils, controller & mdsal but never to 
openflowplugin, ovsdb or any other genius bundles, nor the binding-parent. 
Makes sense?

Specifically which existing classes shall we start that bundle with? Here's my 
initial proposal, for discussion:

* org.opendaylight.genius.datastoreutils.listeners (incl. the 
AbstractClusteredSyncDataTreeChangeListener)
* org.opendaylight.genius.infra (incl. the FutureRpcResults you need; also 
ManagedNewTransactionRunner stuff)
* org.opendaylight.genius.mdsalutil.cache
* org.opendaylight.genius.utils.metrics.DataStoreMetrics only as a non-public 
package local class in the new listeners package
* NOT the SingleTransactionDataBroker - I think we should discourage its use, 
in favour of the ManagedNewTransactionRunner
* NOT org.opendaylight.genius.datastoreutils's @Deprecated Listener helpers, 
BUT MAYBE the Chainable* stuff, IFF (when) we make the new 
genius.datastoreutils.listeners use them for testability
* NOT IMdsalApiManager and org.opendaylight.genius.mdsalutil, 
mdsalutil.actions, mdsalutil.instructions, mdsalutil.[nx]matches (obviously)
* NOT org.opendaylight.genius.mdsalutil.packet
* NOT org.opendaylight.genius.utils.batching (at least not in its current form)
* NOT org.opendaylight.genius.utils
* NOT anything Hwvtep related

We can do this with a few steps, of course; don't have to move everything in 
one big Gerrit change. And we obviously need to keep backwards compatibility at 
least for a while. This should be possible by making mdsalutil-api dependant on 
this new bundle, and delegating. We should very much avoid to simply copy/paste 
ANY code, IMHO.

Could I suggest that we use the opportunity of a new bundle as the occassion to 
set a high bar for code quality? Beyond CS (that's old news), and FB (that's so 
2017), we should mandate also that all code in this new bundle complies with 
findbugs-slf4j (which we're just about to enforce accross all of genius 
anyway), Google's Error-Prone, enforces no copy/paste, has a 100% clean 
classpath without duplicates? This is easy by using the infrautils:parent for 
this new bu

[openflowplugin-dev] Doubt on openflow reconciliation logic

[Faseela K]

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

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

[Faseela K]

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>; 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 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
  ==> tapcad3a2b8-50

I have triggered some more runs, let us see whether we will hit the error or 
not.


Thanks,
Faseela

From: Suja T
Sent: Friday, March 09, 2018 8:06 AM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@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 Faseela,
We have added logs in openflowplugin and we start

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

[Faseela K]

Hi Arun,
   Sam ran CSIT with the openflowplugin + genius patch, and it passed.


  *   95 is full suite
  *   96 is just elan

https://jenkins.opendaylight.org/releng/user/shague/my-views/view/netvirt-fluorine-queens/job/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/95

https://jenkins.opendaylight.org/releng/user/shague/my-views/view/netvirt-fluorine-queens/job/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/96

Thanks,
Faseela

From: D Arunprakash
Sent: Thursday, March 15, 2018 5:05 PM
To: Faseela K <faseel...@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 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
  ==> tapcad3a2b8-50

I have triggered some more runs, let us see whether we will hit the error or 
not.


Thanks,
Faseela

From: Suja T
Sent: Friday, March 09, 2018 8:06 AM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@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.or

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

[Faseela K]

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>; D Arunprakash <d.arunprak...@ericsson.com>; 
'openflowplugin-dev' <openflowplugin-dev@lists.opendaylight.org>
Cc: 'genius-...@lists.opendaylight.org' <genius-...@lists.opendaylight.org>; 
'odl netvirt dev' <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
  ==> tapcad3a2b8-50

I have triggered some more runs, let us see whether we will hit the error or 
not.


Thanks,
Faseela

From: Suja T
Sent: Friday, March 09, 2018 8:06 AM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@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 Faseela,
We have added logs in openflowplugin and we started CSIT to identify whether we 
are receiving the proper reason and updating the reason flag with exact reason.
When there is actual port delete we are submitting the transaction with the 
reason as delete for both update and remove event.
I have verified this scenario for the problematic port which you have mentioned 
for the failing test case.  we are providing the flag with proper reason.

Herewith, the link where we have run CSIT in stable/oxygen and master, and 
given the port name for which I verified this scenarios:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-oxygen/57/odl_1/odl1_karaf.log.gz
  port name: tap7de20c9a-42

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/34/odl_1/odl1_karaf.log.gz
 port name: tapa504adbf-93

Regards,
Suja
From: Faseela K
Sent: Thursday, March 08, 2018 2:02 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: PortReason Flag not set properly during port deletes

Hello openflowplugin-devs,
  We had started using the PortReason Flag given by openflowpl

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

[Faseela K]

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>; D Arunprakash <d.arunprak...@ericsson.com>; 
'openflowplugin-dev' <openflowplugin-dev@lists.opendaylight.org>
Cc: 'genius-...@lists.opendaylight.org' <genius-...@lists.opendaylight.org>; 
'odl netvirt dev' <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
  ==> tapcad3a2b8-50

I have triggered some more runs, let us see whether we will hit the error or 
not.


Thanks,
Faseela

From: Suja T
Sent: Friday, March 09, 2018 8:06 AM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@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 Faseela,
We have added logs in openflowplugin and we started CSIT to identify whether we 
are receiving the proper reason and updating the reason flag with exact reason.
When there is actual port delete we are submitting the transaction with the 
reason as delete for both update and remove event.
I have verified this scenario for the problematic port which you have mentioned 
for the failing test case.  we are providing the flag with proper reason.

Herewith, the link where we have run CSIT in stable/oxygen and master, and 
given the port name for which I verified this scenarios:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-oxygen/57/odl_1/odl1_karaf.log.gz
  port name: tap7de20c9a-42

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/34/odl_1/odl1_karaf.log.gz
 port name: tapa504adbf-93

Regards,
Suja
From: Faseela K
Sent: Thursday, March 08, 2018 2:02 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: PortReason Flag not set properly during port deletes

Hello openflowplugin-devs,
  We had started using the PortReason Flag given by openflowplugin to 
efficiently handle DPN disconnect scenarios in Genius.
  However in certain cases this flag is not coming with the right reason for 
genuine port delete scenarios, and there were failures in netvirt CSIT due to 
this.
  We had to revert the patch in Genius,  and we would like to have a solution 
for the issue, so that the patch can go back in Oxygen, as this is an important 
robustness fix.
  Let me know whether we should raise a JIRA for this.
  We have run netvirt CSIT only for the failing CSIT with respective TRACES 
enabled, the problematic port in the below log is "tapcad3a2b8-50".
  
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

Thanks,
Faseela
___
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

[Faseela K]

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>; D Arunprakash <d.arunprak...@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

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
  ==> tapcad3a2b8-50

I have triggered some more runs, let us see whether we will hit the error or 
not.


Thanks,
Faseela

From: Suja T
Sent: Friday, March 09, 2018 8:06 AM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@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 Faseela,
We have added logs in openflowplugin and we started CSIT to identify whether we 
are receiving the proper reason and updating the reason flag with exact reason.
When there is actual port delete we are submitting the transaction with the 
reason as delete for both update and remove event.
I have verified this scenario for the problematic port which you have mentioned 
for the failing test case.  we are providing the flag with proper reason.

Herewith, the link where we have run CSIT in stable/oxygen and master, and 
given the port name for which I verified this scenarios:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-oxygen/57/odl_1/odl1_karaf.log.gz
  port name: tap7de20c9a-42

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/34/odl_1/odl1_karaf.log.gz
 port name: tapa504adbf-93

Regards,
Suja
From: Faseela K
Sent: Thursday, March 08, 2018 2:02 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: PortReason Flag not set properly during port deletes

Hello openflowplugin-devs,
  We had started using the PortReason Flag given by openflowplugin to 
efficiently handle DPN disconnect scenarios in Genius.
  However in certain cases this flag is not coming with the right reason for 
genuine port delete scenarios, and there were failures in netvirt CSIT due to 
this.
  We had to revert the patch in Genius,  and we would like to have a solution 
for the issue, so that the patch can go back in Oxygen, as this is an important 
robustness fix.
  Let me know whether we should raise a JIRA for this.
  We have run netvirt CSIT only for the failing CSIT with respective TRACES 
enabled, the problematic port in the below log is "tapcad3a2b8-50".
  
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

Thanks,
Faseela
___
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

[Faseela K]

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
  ==> tapcad3a2b8-50

I have triggered some more runs, let us see whether we will hit the error or 
not.


Thanks,
Faseela

From: Suja T
Sent: Friday, March 09, 2018 8:06 AM
To: Faseela K <faseel...@ericsson.com>; D Arunprakash 
<d.arunprak...@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 Faseela,
We have added logs in openflowplugin and we started CSIT to identify whether we 
are receiving the proper reason and updating the reason flag with exact reason.
When there is actual port delete we are submitting the transaction with the 
reason as delete for both update and remove event.
I have verified this scenario for the problematic port which you have mentioned 
for the failing test case.  we are providing the flag with proper reason.

Herewith, the link where we have run CSIT in stable/oxygen and master, and 
given the port name for which I verified this scenarios:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-oxygen/57/odl_1/odl1_karaf.log.gz
  port name: tap7de20c9a-42

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-gate-stateful-fluorine/34/odl_1/odl1_karaf.log.gz
 port name: tapa504adbf-93

Regards,
Suja
From: Faseela K
Sent: Thursday, March 08, 2018 2:02 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: PortReason Flag not set properly during port deletes

Hello openflowplugin-devs,
  We had started using the PortReason Flag given by openflowplugin to 
efficiently handle DPN disconnect scenarios in Genius.
  However in certain cases this flag is not coming with the right reason for 
genuine port delete scenarios, and there were failures in netvirt CSIT due to 
this.
  We had to revert the patch in Genius,  and we would like to have a solution 
for the issue, so that the patch can go back in Oxygen, as this is an important 
robustness fix.
  Let me know whether we should raise a JIRA for this.
  We have run netvirt CSIT only for the failing CSIT with respective TRACES 
enabled, the problematic port in the below log is "tapcad3a2b8-50".
  
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

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

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

[Faseela K]

Hello openflowplugin-devs,
  We had started using the PortReason Flag given by openflowplugin to 
efficiently handle DPN disconnect scenarios in Genius.
  However in certain cases this flag is not coming with the right reason for 
genuine port delete scenarios, and there were failures in netvirt CSIT due to 
this.
  We had to revert the patch in Genius,  and we would like to have a solution 
for the issue, so that the patch can go back in Oxygen, as this is an important 
robustness fix.
  Let me know whether we should raise a JIRA for this.
  We have run netvirt CSIT only for the failing CSIT with respective TRACES 
enabled, the problematic port in the below log is "tapcad3a2b8-50".
  
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

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

[openflowplugin-dev] use feature for inter-project dependency

[Faseela K]

Hello openflowplugin committers,

Could you please review and merge this change? 
https://git.opendaylight.org/gerrit/#/c/68361/
Details of the change is given in the review description.
This is part of  "use feature for inter-project dependency" changes, where 
openflowplugin was not using the same for some of the features.

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

Re: [openflowplugin-dev] Is "model-topology" exposed as a feature?

[Faseela K]

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

Thanks,
Faseela

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Thursday, February 15, 2018 6:12 PM
To: Faseela K <faseel...@ericsson.com>; controller-dev 
<controller-...@lists.opendaylight.org>; mdsal-...@lists.opendaylight.org
Cc: Stephen Kitt <sk...@redhat.com>; Michael Vorburger <vorbur...@redhat.com>; 
openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
Subject: Re: Is "model-topology" exposed as a feature?



On 15/02/18 13:21, Faseela K wrote:
> I am working on removing the inter project bundle dependencies in 
> openflowplugin as part of [0]
> 
> There is a feature odl-openflowplugin-nsf-model in openflowplugin 
> which uses
> 
> 
> 
>  org.opendaylight.controller.model
> 
>     model-topology
> 
>    ${mdsal.version}
> 
> 
> 
>  
> 
> which I don't see in controller being exposed as a feature
> 
> Before working on exposing this as feature, wanted to know whether 
> this is something which was recently migrated to mdsal.

This model will not be migrated to mdsal, as it is considered obsolete, feel 
free to propose to a patch to package it from the controller.

Regards,
Robert

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

Re: [openflowplugin-dev] genius builds broken, due to openflowplugin lldp checkstyle changes

[Faseela K]

Revert patch : https://git.opendaylight.org/gerrit/#/c/68308/

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela 
K
Sent: Thursday, February 15, 2018 8:34 PM
To: N Edwin Anthony <n.edwin.anth...@ericsson.com>; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
release (rele...@lists.opendaylight.org) <rele...@lists.opendaylight.org>
Cc: R Srinivasan E <r.e.sriniva...@ericsson.com>
Subject: Re: [openflowplugin-dev] genius builds broken, due to openflowplugin 
lldp checkstyle changes

+release

Openflowplugin committers,

Can we get the below patch reverted?

Thanks,
Faseela

From: Faseela K
Sent: Thursday, February 15, 2018 6:03 PM
To: 'N Edwin Anthony' 
<n.edwin.anth...@ericsson.com<mailto:n.edwin.anth...@ericsson.com>>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: R Srinivasan E 
<r.e.sriniva...@ericsson.com<mailto:r.e.sriniva...@ericsson.com>>
Subject: RE: genius builds broken, mdsalutil-api is not building

Looks like this patch in openflowplugin needs to be reverted.

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

Thanks,
Faseela

From: 
genius-dev-boun...@lists.opendaylight.org<mailto:genius-dev-boun...@lists.opendaylight.org>
 [mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of N Edwin Anthony
Sent: Thursday, February 15, 2018 6:00 PM
To: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: R Srinivasan E 
<r.e.sriniva...@ericsson.com<mailto:r.e.sriniva...@ericsson.com>>
Subject: [genius-dev] genius builds broken, mdsalutil-api is not building


Hi All,

Genius builds are failing because of the reason:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) 
on project mdsalutil-api: Compilation failure: Compilation failure:
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[157,36]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[492,54]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[518,65]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[587,46]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[185,58]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[189,76]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[226,79]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils

are others facing similar issues ?
https://jenkins.opendaylight.org/releng/job/genius-distribution-check-oxygen/1210/console

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

Re: [openflowplugin-dev] genius builds broken, due to openflowplugin lldp checkstyle changes

[Faseela K]

+release

Openflowplugin committers,

Can we get the below patch reverted?

Thanks,
Faseela

From: Faseela K
Sent: Thursday, February 15, 2018 6:03 PM
To: 'N Edwin Anthony' <n.edwin.anth...@ericsson.com>; 
genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org
Cc: R Srinivasan E <r.e.sriniva...@ericsson.com>
Subject: RE: genius builds broken, mdsalutil-api is not building

Looks like this patch in openflowplugin needs to be reverted.

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

Thanks,
Faseela

From: 
genius-dev-boun...@lists.opendaylight.org<mailto:genius-dev-boun...@lists.opendaylight.org>
 [mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of N Edwin Anthony
Sent: Thursday, February 15, 2018 6:00 PM
To: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: R Srinivasan E 
<r.e.sriniva...@ericsson.com<mailto:r.e.sriniva...@ericsson.com>>
Subject: [genius-dev] genius builds broken, mdsalutil-api is not building


Hi All,

Genius builds are failing because of the reason:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) 
on project mdsalutil-api: Compilation failure: Compilation failure:
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[157,36]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[492,54]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[518,65]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[587,46]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[185,58]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[189,76]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[226,79]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils

are others facing similar issues ?
https://jenkins.opendaylight.org/releng/job/genius-distribution-check-oxygen/1210/console

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

Re: [openflowplugin-dev] genius builds broken, mdsalutil-api is not building

[Faseela K]

Looks like this patch in openflowplugin needs to be reverted.

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

Thanks,
Faseela

From: genius-dev-boun...@lists.opendaylight.org 
[mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of N Edwin Anthony
Sent: Thursday, February 15, 2018 6:00 PM
To: genius-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org
Cc: R Srinivasan E 
Subject: [genius-dev] genius builds broken, mdsalutil-api is not building


Hi All,

Genius builds are failing because of the reason:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) 
on project mdsalutil-api: Compilation failure: Compilation failure:
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[157,36]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[492,54]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[518,65]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/IPv4.java:[587,46]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[185,58]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[189,76]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils
11:15:19 [ERROR] 
/w/workspace/genius-distribution-check-oxygen/genius/mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/packet/ICMP.java:[226,79]
 cannot find symbol
11:15:19 [ERROR] symbol:   variable NumBitsInAByte
11:15:19 [ERROR] location: class 
org.opendaylight.openflowplugin.libraries.liblldp.NetUtils

are others facing similar issues ?
https://jenkins.opendaylight.org/releng/job/genius-distribution-check-oxygen/1210/console

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

[openflowplugin-dev] Is "model-topology" exposed as a feature?

[Faseela K]

I am working on removing the inter project bundle dependencies in 
openflowplugin as part of [0]
There is a feature odl-openflowplugin-nsf-model in openflowplugin which uses

 org.opendaylight.controller.model
model-topology
   ${mdsal.version}


which I don't see in controller being exposed as a feature
Before working on exposing this as feature, wanted to know whether this is 
something which was recently migrated to mdsal.


Thanks,
Faseela

[0] https://jira.opendaylight.org/browse/OPNFLWPLUG-976

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

[openflowplugin-dev] Export LLDP library as feature

[Faseela K]

Hello openflowplugin committers,

Could you please review and merge this change? 
https://git.opendaylight.org/gerrit/#/c/68233/
Details of the change is given in the review description.
This is needed for netvirt as well as genius, and we have run netvirt CSIT with 
a multi-patch build where all the dependent changes were built together.

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

Re: [openflowplugin-dev] [genius-dev] While migrating Vm instances, connection failed between the VM instances.

[Faseela K]

Hi Arun,
  Hari is executing a series of VM migrations, and at some random times, he 
observes that NodeConnetor add event for the migrated VM comes with 
PortReason.Update, and hence we ignore the event.
  Could you please give us some pointers on when this can happen?
Thanks,
Faseela



From: Nobin Mathew
Sent: Wednesday, February 07, 2018 7:24 PM
To: Hari Prasad <hari...@hcl.com>; Faseela K <faseel...@ericsson.com>; 
genius-...@lists.opendaylight.org
Cc: Venkatrangan G - ERS, HCL Tech <venkatrang...@hcl.com>; D Arunprakash 
<d.arunprak...@ericsson.com>
Subject: RE: [genius-dev] While migrating Vm instances, connection failed 
between the VM instances.

Yes it is the same reason.

Someone from openflow plugin side has to debug further.

-Nobin


From: Hari Prasad [mailto:hari...@hcl.com]
Sent: Wednesday, February 07, 2018 6:00 PM
To: Nobin Mathew; Faseela K; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Cc: Venkatrangan G - ERS, HCL Tech; D Arunprakash
Subject: RE: [genius-dev] While migrating Vm instances, connection failed 
between the VM instances.

Hi Nobin,

Yes, We can see from below debug log portReason as 'UPDATE' instead of 'ADD' 
for failure port.

Successful Vm instance: (Add event)
---
2018-02-01 01:48:55,831 | DEBUG | eChangeHandler-0 | 
InterfaceInventoryStateListener  | 232 - 
org.opendaylight.genius.interfacemanager-impl - 0.3.0 | Received NodeConnector 
Add Event: InstanceIdentifier{targetType=interface 
org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.FlowCapableNodeConnector,
 path=[org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.Nodes, 
org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node[key=NodeKey
 [_id=Uri [_value=openflow:615256118989]]], 
org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.node.NodeConnector[key=NodeConnectorKey
 [_id=Uri [_value=openflow:615256118989:5]]], 
org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.FlowCapableNodeConnector]},
 FlowCapableNodeConnector{getAdvertisedFeatures=PortFeatures [_tenMbHd=false, 
_tenMbFd=false, _hundredMbHd=false, _hundredMbFd=false, _oneGbHd=false, 
_oneGbFd=false, _tenGbFd=false, _fortyGbFd=false, _hundredGbFd=false, 
_oneTbFd=false, _other=false, _copper=false, _fiber=false, _autoeng=false, 
_pause=false, _pauseAsym=false], getConfiguration=PortConfig [_pORTDOWN=true, 
_nORECV=false, _nOFWD=false, _nOPACKETIN=false], getCurrentFeature=PortFeatures 
[_tenMbHd=false, _tenMbFd=true, _hundredMbHd=false, _hundredMbFd=false, 
_oneGbHd=false, _oneGbFd=false, _tenGbFd=false, _fortyGbFd=false, 
_hundredGbFd=false, _oneTbFd=false, _other=false, _copper=true, _fiber=false, 
_autoeng=false, _pause=false, _pauseAsym=false], getCurrentSpeed=1, 
getHardwareAddress=MacAddress [_value=fe:16:3e:25:00:bc], getMaximumSpeed=0, 
getName=tap5be6a5a8-f9, getPeerFeatures=PortFeatures [_tenMbHd=false, 
_tenMbFd=false, _hundredMbHd=false, _hundredMbFd=false, _oneGbHd=false, 
_oneGbFd=false, _tenGbFd=false, _fortyGbFd=false, _hundredGbFd=false, 
_oneTbFd=false, _other=false, _copper=false, _fiber=false, _autoeng=false, 
_pause=false, _pauseAsym=false], getPortNumber=PortNumberUni [_uint32=5], 
getQueue=[], getReason=Add, getState=State{isBlocked=false, isLinkDown=true, 
isLive=false, augmentations={}}, getSupported=PortFeatures [_tenMbHd=false, 
_tenMbFd=false, _hundredMbHd=false, _hundredMbFd=false, _oneGbHd=false, 
_oneGbFd=false, _tenGbFd=false, _fortyGbFd=false, _hundredGbFd=false, 
_oneTbFd=false, _other=false, _copper=false, _fiber=false, _autoeng=false, 
_pause=false, _pauseAsym=false]}

Failure Vm instance: (Add event)
---
2018-02-01 01:49:05,833 | DEBUG | eChangeHandler-0 | 
InterfaceInventoryStateListener  | 232 - 
org.opendaylight.genius.interfacemanager-impl - 0.3.0 | Received NodeConnector 
Add Event: InstanceIdentifier{targetType=interface 
org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.FlowCapableNodeConnector,
 path=[org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.Nodes, 
org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.nodes.Node[key=NodeKey
 [_id=Uri [_value=openflow:615256118989]]], 
org.opendaylight.yang.gen.v1.urn.opendaylight.inventory.rev130819.node.NodeConnector[key=NodeConnectorKey
 [_id=Uri [_value=openflow:615256118989:6]]], 
org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.FlowCapableNodeConnector]},
 FlowCapableNodeConnector{getAdvertisedFeatures=PortFeatures [_tenMbHd=false, 
_tenMbFd=false, _hundredMbHd=false, _hundredMbFd=false, _oneGbHd=false, 
_oneGbFd=false, _tenGbFd=false, _fortyGbFd=false, _hundredGbFd=false, 
_oneTbFd=false, _other=false, _copper=false, _fiber=false, _autoeng=false, 
_pause=false, _pauseAsym=false], getConfiguration=PortConfig [_pORTDOWN=false, 
_nORECV=false, _nOFWD=false, _nOPACKETIN=false], 

Re: [openflowplugin-dev] OVS 2.8?

[Faseela K]

I was just testing OVS2.8 with netvirt today, and when I did the below line, 
things started working.
Till that not even default flows were showing up, however switch was showing 
is_connected : true.

Thanks,
Faseela

From: Josh Hershberg [mailto:jhers...@redhat.com]
Sent: Monday, February 05, 2018 10:17 PM
To: Faseela K <faseel...@ericsson.com>
Cc: Sam Hague <sha...@redhat.com>; Ryan Goulding <ryandgould...@gmail.com>; odl 
netvirt dev <netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] OVS 2.8?

Very possibly ;-) Like I said, I didn't investigate at all but sounds promising.

On Mon, Feb 5, 2018 at 6:11 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Josh,

  When we add bridge on OVS 2.8, we have to do “ovs-vsctl set bridge br-int 
protocols= OpenFlow13” for things to work properly. Is that what you are 
missing?

Thanks,

Faseela


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 Sam Hague
Sent: Monday, February 05, 2018 8:27 PM
To: Ryan Goulding <ryandgould...@gmail.com<mailto:ryandgould...@gmail.com>>
Cc: odl netvirt dev 
<netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>>;
 genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Subject: Re: [openflowplugin-dev] OVS 2.8?

Yeah, Luis found some issues with ovs 2.8.1. Main issue was the default is of 
1.4 - which ODL does not support, so you need to force 1.3.

[1] is a patch he has to adjust ofp csit. We will need something similar for 
netvirt when we move off of ovs 2.7.x

[1] https://git.opendaylight.org/gerrit/#/c/67850/

On Mon, Feb 5, 2018 at 9:38 AM, Ryan Goulding 
<ryandgould...@gmail.com<mailto:ryandgould...@gmail.com>> wrote:
[0] contains the conversation, in which he provides a few suggestions.  I 
haven't tried yet though.

Regards,

Ryan Goulding

[0] 
https://lists.opendaylight.org/pipermail/integration-dev/2018-February/010897.html

On Mon, Feb 5, 2018 at 9:27 AM, Josh Hershberg 
<jhers...@redhat.com<mailto:jhers...@redhat.com>> wrote:
Yes, mine was also 2.8.1.

On Mon, Feb 5, 2018 at 4:27 PM, Ryan Goulding 
<ryandgould...@gmail.com<mailto:ryandgould...@gmail.com>> wrote:
Adding Luis too, as he was trying.  I see the same thing w/ 2.8.1...

Regards,

Ryan Goulding

On Mon, Feb 5, 2018 at 9:25 AM, Josh Hershberg 
<jhers...@redhat.com<mailto:jhers...@redhat.com>> wrote:
​I recently tried OVS 2.8 and things did not go well. OF connected and hello's 
were flowing but nothing else got sent at all. I did not debug or investigate 
at all. I'm just curious if this is a known issue or if there's something 
obviously screwy about my setup. Anyone know anything about this?​

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




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


___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org<mailto: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] stable/carbon: config parent 0.6.3-SNAPSHOT version missing from nexus https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/controller/co

[Faseela K]

Carbon builds are failing for genius as well.

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of D 
Arunprakash
Sent: Wednesday, January 31, 2018 12:30 PM
To: Release 
Cc: openflowplugin-dev 
Subject: [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-parent/

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] How to do cookie based flow deletion

[Faseela K]

+genius-dev

From: Faseela K
Sent: Saturday, December 16, 2017 9:44 PM
To: Vishal Thapar <vishal.tha...@ericsson.com>; Anil Vishnoi 
<vishnoia...@gmail.com>
Cc: openflowplugin-dev@lists.opendaylight.org; Vinayak Joshi 
<vinayak.jo...@ericsson.com>; Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com>; N Vivekanandan 
<n.vivekanan...@ericsson.com>
Subject: RE: [openflowplugin-dev] How to do cookie based flow deletion

Yes Vishal!
This was the point I was coming to, just wanted to know whether there are 
already available solutions.
Let us see if there are any other suggestions or thoughts on the same.

Thanks,
Faseela

From: Vishal Thapar
Sent: Saturday, December 16, 2017 9:38 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Anil 
Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: RE: [openflowplugin-dev] How to do cookie based flow deletion

Hi Faseela,

Isn’t this the sort of use case Genius supposed to enable?

Way current model for OF flows is, key is flow-id. This makes for easy deletion 
of individual flows in most cases, without having to provide exact match, which 
switch requires.

Even if OFPlugin were to enable bulk delete of flows using cookies, 
applications will still have to cleanup flows from DataStore.

So, why not solve problem in MdsalUtils in Genius, at least for applications 
that do already use Genius? I had come up with a design of sorts for this 
sometime back as a potential Internship mini-project as part of my wishlist for 
Genius improvements. Will dig and see if I can find it.

Regards,
Vishal.

From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Faseela K
Sent: 16 December 2017 21:18
To: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] How to do cookie based flow deletion

Yes Anil! There is a limitation due to the fact that we are using the 
datastore, and we cannot bypass the datastore since we need other features that 
we get by having data written to the datastore.
Since openflow spec allows deletion based on cookie, is there a way this can be 
solved in a generic manner, so that all apps can benefit out of it? Each app 
maintaining cookie to flow-id list within themselves and doing a delete based 
on that, looks like an overhead.

Thanks,
Faseela

From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Saturday, December 16, 2017 1:15 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] How to do cookie based flow deletion

I believe data store don't allow matching based delete, you can probably do 
bulk delete by deleting the entire node, but i believe that is not what you are 
looking for. Openflowplugin depends on how data is modified in the data store, 
it just acts to the data modification notification that it receives from data 
store. So as far as i know, this is a limitation from data store side. As an 
alternative you can use deleteFlow rpc that plugin expose, but again in that 
case cleaning the data store is users responsibility, because if switch will 
reconnect, all the flows will end up in the switch because they are still 
present in the config data store. It might not be that useful in your case, but 
i think that depends on the usecase.

On Fri, Dec 15, 2017 at 9:24 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hello,
   We in genius use opendaylight-inventory-nodes config DS, as the method to 
push flows to the switch.
   But there are several delete use-cases, where a deletion based on a cookie 
which will be far easier for us.
   Is there a way to do this, because we want to delete all entries in the 
config DS which matches for a particular flow cookie?
Thanks,
Faseela

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



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

Re: [openflowplugin-dev] How to do cookie based flow deletion

[Faseela K]

Yes Vishal!
This was the point I was coming to, just wanted to know whether there are 
already available solutions.
Let us see if there are any other suggestions or thoughts on the same.

Thanks,
Faseela

From: Vishal Thapar
Sent: Saturday, December 16, 2017 9:38 PM
To: Faseela K <faseel...@ericsson.com>; Anil Vishnoi <vishnoia...@gmail.com>
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: RE: [openflowplugin-dev] How to do cookie based flow deletion

Hi Faseela,

Isn’t this the sort of use case Genius supposed to enable?

Way current model for OF flows is, key is flow-id. This makes for easy deletion 
of individual flows in most cases, without having to provide exact match, which 
switch requires.

Even if OFPlugin were to enable bulk delete of flows using cookies, 
applications will still have to cleanup flows from DataStore.

So, why not solve problem in MdsalUtils in Genius, at least for applications 
that do already use Genius? I had come up with a design of sorts for this 
sometime back as a potential Internship mini-project as part of my wishlist for 
Genius improvements. Will dig and see if I can find it.

Regards,
Vishal.

From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Faseela K
Sent: 16 December 2017 21:18
To: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] How to do cookie based flow deletion

Yes Anil! There is a limitation due to the fact that we are using the 
datastore, and we cannot bypass the datastore since we need other features that 
we get by having data written to the datastore.
Since openflow spec allows deletion based on cookie, is there a way this can be 
solved in a generic manner, so that all apps can benefit out of it? Each app 
maintaining cookie to flow-id list within themselves and doing a delete based 
on that, looks like an overhead.

Thanks,
Faseela

From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Saturday, December 16, 2017 1:15 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] How to do cookie based flow deletion

I believe data store don't allow matching based delete, you can probably do 
bulk delete by deleting the entire node, but i believe that is not what you are 
looking for. Openflowplugin depends on how data is modified in the data store, 
it just acts to the data modification notification that it receives from data 
store. So as far as i know, this is a limitation from data store side. As an 
alternative you can use deleteFlow rpc that plugin expose, but again in that 
case cleaning the data store is users responsibility, because if switch will 
reconnect, all the flows will end up in the switch because they are still 
present in the config data store. It might not be that useful in your case, but 
i think that depends on the usecase.

On Fri, Dec 15, 2017 at 9:24 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hello,
   We in genius use opendaylight-inventory-nodes config DS, as the method to 
push flows to the switch.
   But there are several delete use-cases, where a deletion based on a cookie 
which will be far easier for us.
   Is there a way to do this, because we want to delete all entries in the 
config DS which matches for a particular flow cookie?
Thanks,
Faseela

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



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

Re: [openflowplugin-dev] How to do cookie based flow deletion

[Faseela K]

Yes Anil! There is a limitation due to the fact that we are using the 
datastore, and we cannot bypass the datastore since we need other features that 
we get by having data written to the datastore.
Since openflow spec allows deletion based on cookie, is there a way this can be 
solved in a generic manner, so that all apps can benefit out of it? Each app 
maintaining cookie to flow-id list within themselves and doing a delete based 
on that, looks like an overhead.

Thanks,
Faseela

From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Saturday, December 16, 2017 1:15 PM
To: Faseela K <faseel...@ericsson.com>
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] How to do cookie based flow deletion

I believe data store don't allow matching based delete, you can probably do 
bulk delete by deleting the entire node, but i believe that is not what you are 
looking for. Openflowplugin depends on how data is modified in the data store, 
it just acts to the data modification notification that it receives from data 
store. So as far as i know, this is a limitation from data store side. As an 
alternative you can use deleteFlow rpc that plugin expose, but again in that 
case cleaning the data store is users responsibility, because if switch will 
reconnect, all the flows will end up in the switch because they are still 
present in the config data store. It might not be that useful in your case, but 
i think that depends on the usecase.

On Fri, Dec 15, 2017 at 9:24 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hello,
   We in genius use opendaylight-inventory-nodes config DS, as the method to 
push flows to the switch.
   But there are several delete use-cases, where a deletion based on a cookie 
which will be far easier for us.
   Is there a way to do this, because we want to delete all entries in the 
config DS which matches for a particular flow cookie?
Thanks,
Faseela

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



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

[openflowplugin-dev] How to do cookie based flow deletion

[Faseela K]

Hello,
   We in genius use opendaylight-inventory-nodes config DS, as the method to 
push flows to the switch.
   But there are several delete use-cases, where a deletion based on a cookie 
which will be far easier for us.
   Is there a way to do this, because we want to delete all entries in the 
config DS which matches for a particular flow cookie?
Thanks,
Faseela
___
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

[Faseela K]

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: t...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org
Subject: [OpenDaylight TSC] New OpenFlow Plugin PTL

Since there is no other OpenFlow Plugin committer contesting the OpenFlow 
Plugin PTL election other than Anil Vishnoi, he is the new PTL.

Congrats Anil - you got a lot of courage :)

Release / TSC - please note the change.


On Sun, Dec 3, 2017 at 8:29 PM, Abhijit Kumbhare 
> wrote:
Great! If no one else comes forward by the end of the week - we should 
formalize it on Friday.

On Sun, Dec 3, 2017 at 6:47 PM, Anil Vishnoi 
> wrote:
Hi Abhijit,

I would like to nominate myself for the PTL role.

Thanks
Anil



On Dec 3, 2017, at 5:03 PM, Abhijit Kumbhare 
> wrote:
Hi OpenFlow Plugin committers,

If you would like to be the PTL for the project - please self nominate. If 
there are multiple candidates we will have an election.

Abhijit

On Sun, Dec 3, 2017 at 4:59 PM, Abhijit Kumbhare 
> wrote:
Hi folks,

Having been the PTL for OpenFlow Plugin from almost the first Hydrogen release, 
it would be a good time to handover the baton to someone else. I am really not 
going anywhere - but will continue to be involved in ODL overall.

Will send a separate email on the OpenFlow Plugin mailing list for self 
nominations.

- Abhijit


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


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

___
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] Proposing infrautils.ready integration for openflowplugin

[Faseela K]

Hi Arun,
   DATASTORE service patch was initially proposed in controller, and we need to 
work on some more documentation stuff in infrautils to get this there finally. 
Genius is just a temporary placeholder for the same, till things get sorted out.
Thanks,
Faseela

From: Muthukumaran K
Sent: Monday, November 27, 2017 11:47 AM
To: D Arunprakash <d.arunprak...@ericsson.com>; Faseela K 
<faseel...@ericsson.com>; openflowplugin-dev@lists.opendaylight.org
Cc: infrautils-...@lists.opendaylight.org; Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com>; Tom Pantelis <tompante...@gmail.com>
Subject: RE: [openflowplugin-dev] Proposing infrautils.ready integration for 
openflowplugin

IMO, we can start with system ready to begin with since OFP cannot have Genius 
as runtime dependency

Regards
Muthu


From: D Arunprakash
Sent: Monday, November 27, 2017 11:42 AM
To: Muthukumaran K; Faseela K; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>;
 Dayavanti Gopal Kamath; Tom Pantelis
Subject: RE: [openflowplugin-dev] Proposing infrautils.ready integration for 
openflowplugin

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>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Muthukumaran K
Sent: Thursday, November 23, 2017 11:19 AM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>;
 Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com<mailto:dayavanti.gopal.kam...@ericsson.com>>;
 Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>>
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<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto: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 <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>;
 Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>; Dayavanti Gopal 
Kamath 
<dayavanti.gopal.kam...@ericsson.com<mailto:dayavanti.gopal.kam...@ericsson.com>>;
 Vivek Srivastava V 
<vivek.v.srivast...@ericsson.com<mailto:vivek.v.srivast...@ericsson.com>>
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<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>;
 Sam Hague; Dayavanti Gopal Kamath; Vivek Srivastava V; Muthukumaran K

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

[Faseela K]

Arun,
   It is not “installation by boot features property”, but it is “the features 
that are installed along with infrautils.ready”.
   If you even install manually the first feature that includes 
infrautils.ready, you will get system ready notification as expected. But if 
you install one more feature after a long gap, there won’t be any state change 
notification, it is still a work in progress.
Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Friday, November 24, 2017 4:42 PM
To: D Arunprakash <d.arunprak...@ericsson.com>
Cc: Muthukumaran K <muthukumara...@ericsson.com>; Faseela K 
<faseel...@ericsson.com>; openflowplugin-dev@lists.opendaylight.org; 
infrautils-...@lists.opendaylight.org; Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com>; Tom Pantelis <tompante...@gmail.com>
Subject: Re: [openflowplugin-dev] Proposing infrautils.ready integration for 
openflowplugin

On Fri, Nov 24, 2017 at 7:39 AM, D Arunprakash 
<d.arunprak...@ericsson.com<mailto:d.arunprak...@ericsson.com>> wrote:
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?

No. infrautils.ready, on top of which infrautils.diagstatus is built, currently 
only serves the simple "installation by boot features property" approach. It 
basically does a polling of the OSGi APIs (using odlparent.bundlestest FYI), 
one time during start up.

In theory it would certainly be possible to extend infrautils.diagstatus => 
infrautils.ready and it's 
org.opendaylight.infrautils.ready.SystemReadyListener's onSystemBootReady() 
with an onSystemIsChanging() and onSystemReadyAgain(). But in the primary use 
case I have to support (downstream), "hot" installing additional ODL 
application features during operational uptime is not a real world requirement. 
If this is important to you, then your contributions for this would certainly 
be welcome.

Regards,
Arun

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 Muthukumaran K
Sent: Thursday, November 23, 2017 11:19 AM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>;
 Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com<mailto:dayavanti.gopal.kam...@ericsson.com>>;
 Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>>
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<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto: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 <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>;
 Sam Hague <sha...@redhat.com<mailto:sha...@redhat.com>>; Dayavanti Gopal 
Kamath 
<dayavanti.gopal.kam...@ericsson.com<mailto:dayavanti.gopal.kam...@ericsson.com>>;
 Vivek Srivastava V 
<vivek.v.srivast...@ericsson.com<mailto:vivek.v.srivast...@ericsson.com>>
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 

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

[Faseela K]

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 <faseel...@ericsson.com>; 
openflowplugin-dev@lists.opendaylight.org
Cc: infrautils-...@lists.opendaylight.org; Sam Hague <sha...@redhat.com>; 
Dayavanti Gopal Kamath <dayavanti.gopal.kam...@ericsson.com>; Vivek Srivastava 
V <vivek.v.srivast...@ericsson.com>
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<mailto:openflowplugin-dev@lists.opendaylight.org>
Cc: 
infrautils-...@lists.opendaylight.org<mailto: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] openflowplugin master build error

[Faseela K]

Hi Arun,
Thanks!
This was pretty complex to debug.
In the final error list, I saw only several of Javadoc errors, and this 
particular one comes in several of the other checkstyle warnings :)
And looks like build fails only when new checkstyle errors are being added, 
but that too looks too difficult to figure out from the console log.
Thanks,
Faseela

From: D Arunprakash
Sent: Monday, October 16, 2017 12:04 PM
To: Faseela K <faseel...@ericsson.com>; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: openflowplugin master build error

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>
 [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<mailto: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] [netvirt-dev] netvirt daily CSIT report (9/1)

[Faseela K]

Kiran,
   Could you please check if the tests wait for enough time before doing the 
PING test? Is it just a timing issue? Or is it that the flows never get 
programmed?
Thanks,
Faseela

-Original Message-
From: Kiran N Upadhyaya 
Sent: Tuesday, September 05, 2017 1:58 PM
To: Faseela K <faseel...@ericsson.com>; N Vivekanandan 
<n.vivekanan...@ericsson.com>; netvirt-...@lists.opendaylight.org; Aswin 
Suryanarayanan <asury...@redhat.com>; genius-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org
Subject: RE: [netvirt-dev] netvirt daily CSIT report (9/1)

Thanks Faseela, Aswin.

To re-iterate our observations...
>From the inventory dumps, we can see that a REG6=199f match in table-220 sets 
>REG6=90199f. This will ultimately match on resubmit to table-220 and will 
>proceed as required.
However, on the COMPUTE_2 flow-dumps, a REG6=199f match sets REG6=a0199f. This 
will lead to packet drop when the packet is finally resubmitted to table-220.
We will have to figure out why the expected table-220 flow was not sync'ed to 
the switch.

Requesting openflowplugin-dev experts to further analyze this issue.

Here's the link to the CSIT logs:
https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-3node-openstack-ocata-upstream-stateful-nitrogen/152/log.html.gz#s1-s2-s2-t21

Thanks,
Kiran

-Original Message-
From: Faseela K 
Sent: Tuesday, September 05, 2017 6:56 AM
To: N Vivekanandan; Kiran N Upadhyaya; netvirt-...@lists.opendaylight.org; 
Aswin Suryanarayanan; genius-...@lists.opendaylight.org
Subject: RE: [netvirt-dev] netvirt daily CSIT report (9/1)

Kiran,
   I have checked the logs and see that the flows are correctly programmed in 
inventory config DS, but switch shows up something different.
   Is there a chance that it is taking some more time to update flows on the 
switch, else this might be an openflowplugin bug, but I am not sure about the 
chances for that. 
Thanks,
Faseela

-Original Message-
From: netvirt-dev-boun...@lists.opendaylight.org 
[mailto:netvirt-dev-boun...@lists.opendaylight.org] On Behalf Of N Vivekanandan
Sent: Monday, September 04, 2017 8:07 PM
To: Kiran N Upadhyaya <kiran.n.upadhy...@ericsson.com>; 
netvirt-...@lists.opendaylight.org; Aswin Suryanarayanan <asury...@redhat.com>; 
genius-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] netvirt daily CSIT report (9/1)

'included Genius-dev on this bug analysis, as Table 220 is managed by Interface 
Manager.

-Original Message-
From: Kiran N Upadhyaya 
Sent: Monday, September 04, 2017 4:32 PM
To: netvirt-...@lists.opendaylight.org; Aswin Suryanarayanan 
<asury...@redhat.com>
Cc: Jamo Luhrsen <jluhr...@gmail.com>; N Vivekanandan 
<n.vivekanan...@ericsson.com>
Subject: RE: [netvirt-dev] netvirt daily CSIT report (9/1)

Hi,

I took an initial look at the BUG 9086(CSIT 3node failures - L3 Tests - 
instance to instance connectivity failures), and it seems to be caused due a 
mismatch in the REG6 value added in table-220 and the match in table-220 once 
the EGRESS_ACL_FILTER_TABLE resubmits it..

90.0.0.12 is being pinged.
The flows, on the DPN that hosts 90.0.0.12 are :
cookie=0x9001772, duration=228.405s, table=36, n_packets=175, n_bytes=17312, 
priority=5,tun_id=0x5b 
actions=write_metadata:0x177200/0xf00,goto_table:51
cookie=0x8031772, duration=218.841s, table=51, n_packets=72, n_bytes=7710, 
priority=20,metadata=0x177200/0x00,dl_dst=fa:16:3e:74:39:64 
actions=load:0x199f00->NXM_NX_REG6[],resubmit(,220)
cookie=0x690, duration=228.402s, table=220, n_packets=125, n_bytes=11456, 
priority=6,reg6=0x199f00 
actions=load:0xa0199f00->NXM_NX_REG6[],write_metadata:0x177200/0xfe,goto_table:239
cookie=0x690, duration=228.404s, table=239, n_packets=79, n_bytes=7742, 
priority=62020,ct_state=+trk,ip actions=ct(table=241)  cookie=0x690, 
duration=228.404s, table=239, n_packets=4709, n_bytes=471557, priority=61010 
actions=goto_table:241 cookie=0x690, duration=228.404s, table=241, 
n_packets=68, n_bytes=6870, 
priority=61010,ip,dl_dst=fa:16:3e:74:39:64,nw_dst=90.0.0.12 
actions=ct(table=242,zone=6002) cookie=0x690, duration=228.402s, table=242, 
n_packets=3668, n_bytes=407318, priority=0 actions=goto_table:243 
cookie=0x690, duration=228.402s, table=243, n_packets=3556, n_bytes=379174, 
priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,220)

But, in table-220(EGRESS_LPORT_DISPATCHER_TABLE) there is no match for REG6= 
a0199f00.

@Aswin : Could you please take a glance at the above flows and validate my 
analysis?

Regards,
Kiran


-Original Message-
From: N Vivekanandan
Sent: Monday, September 04, 2017 9:50 AM
To: Chetan Arakere Gowdru; Karthikeyan Krishnan; Kiran N Upadhyaya; P Govinda 
Rajulu; Manu B
Cc: Jamo Luhrsen; netvirt-...@lists.opendaylight.org
Subject: RE: [netvirt-dev] netvirt daily CSIT report (9/1)

Chetan/Karthikeyan,
Can one o

Re: [openflowplugin-dev] [controller-dev] [OpenDaylight TSC] Nitrogen RC1 Build CSIT Failures

[Faseela K]

Genius csit failure is a script issue.
Vidya is working on script fixes here : 
https://git.opendaylight.org/gerrit/60239
Not merged yet!

Thanks,
Faseela

-Original Message-
From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Jamo Luhrsen
Sent: Saturday, August 26, 2017 4:30 AM
To: Kit Lou ; rele...@lists.opendaylight.org; 
aaa-...@lists.opendaylight.org; bgpcep-...@lists.opendaylight.org; 
bier-...@lists.opendaylight.org; coe-...@lists.opendaylight.org; 
controller-...@lists.opendaylight.org; dluxap...@lists.opendaylight.org; 
genius-...@lists.opendaylight.org; groupbasedpolicy-...@lists.opendaylight.org; 
integration-...@lists.opendaylight.org; 
lispflowmapping-...@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; 
netconf-...@lists.opendaylight.org; netvirt-...@lists.opendaylight.org; 
nic-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
ovsdb-...@lists.opendaylight.org; sfc-...@lists.opendaylight.org; 
snmp-...@lists.opendaylight.org; sxp-...@lists.opendaylight.org; 
topoprocessing-...@lists.opendaylight.org; unimgr-...@lists.opendaylight.org; 
usc-...@lists.opendaylight.org; vtn-...@lists.opendaylight.org; 
yangtools-...@lists.opendaylight.org
Cc: t...@lists.opendaylight.org
Subject: Re: [controller-dev] [OpenDaylight TSC] Nitrogen RC1 Build CSIT 
Failures

Netvirt has a lot of problems, mostly all due to the same (assuming) clustering 
issues we saw in carbon. I think those are mostly resolved now with hard work 
from people like Sam, Robert and Tom. But, I don't think those changes were 
merged in nitrogen when the autorelease job ran which triggered these tests.

We need a respin, I think.

If not that, I can file some blocker bug(s) for us to track the problems we see 
in the netvirt CSIT.

Thanks,
JamO

On 08/23/2017 09:28 PM, Kit Lou wrote:
> Hello Nitrogen Projects,
> 
> This email applies to the following projects which have CSIT failures with 
> our RC1 Build:
> 
>   * aaa
>   * bgpcep
>   * bier
>   * coe
>   * controller
>   * distribution
>   * dluxapps
>   * genius
>   * groupbasedpolicy
>   * lispflowmapping
>   * mdsal
>   * netconf
>   * netvirt
>   * nic
>   * openflowplugin
>   * ovsdb
>   * sfc
>   * snmp
>   * sxp
>   * topoprocessing
>   * unimgr
>   * usc
>   * vtn
>   * yangtools
> 
> Please review the failures captured in the tracking spreadsheet [1] 
> below and update the results as soon as possible.  If there are blocker bugs, 
> please open and record it under the "Blocker Bugs" tab in the same 
> spreadsheet.
> 
> Request that you do this by the end of the week.  Thank you!
> 
> Best Regards,
> Kit Lou
> 
> [1] 
> https://docs.google.com/spreadsheets/d/1MYyGLFWN2RzUkJl8XMzXQ-3zWuOrUC
> QpIS6ORbmf4_U/edit#gid=129813418 
>  CQpIS6ORbmf4_U/edit#gid=129813418>
> 
> 
> 
> ___
> TSC mailing list
> t...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/tsc
> 
___
controller-dev mailing list
controller-...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

[openflowplugin-dev] Genius stable/carbon SFTs failing

[Faseela K]

+genius-dev

Some of our stable/carbon patches are failing on SingleFeaturesTest with below 
errors :

08:09:46 1. NOK org.opendaylight.openflowjava.blueprint-config: OSGi state = 
Active, Karaf bundleState = GracePeriod, due to: Blueprint
08:09:46 8/8/17 8:09 AM
08:09:46 Missing dependencies:
08:09:46 
(&(|(type=default)(!(type=*)))(objectClass=org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer))
 
(&(|(type=default)(!(type=*)))(objectClass=org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer))
08:09:46
08:09:46 2. NOK org.opendaylight.openflowplugin.blueprint-config: OSGi state = 
Active, Karaf bundleState = GracePeriod, due to: Blueprint
08:09:46 8/8/17 8:09 AM
08:09:46 Missing dependencies:
08:09:46 
(objectClass=org.opendaylight.openflowjava.protocol.spi.connection.SwitchConnectionProvider)
 Initial app config OpenflowProviderConfig 
(objectClass=org.opendaylight.openflowjava.protocol.spi.connection.SwitchConnectionProvider)
08:09:46
08:09:46 3. NOK org.opendaylight.openflowplugin.applications.lldp-speaker: OSGi 
state = Active, Karaf bundleState = GracePeriod, due to: Blueprint
08:09:46 8/8/17 8:09 AM
08:09:46 Missing dependencies:
08:09:46 Initial app config LldpSpeakerConfig

https://jenkins.opendaylight.org/releng/job/genius-verify-carbon-mvn33-openjdk8/2343/console



Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of 
Gobinath .
Sent: Tuesday, August 08, 2017 11:47 AM
To: openflowplugin-dev@lists.opendaylight.org
Subject: [openflowplugin-dev] CSIT broken for openflowplugin ?

Hi,

CSIT had failed for my patch in openflowplugin. I could see that CSIT failing 
for other recent jobs too. Is CSIT broken for openflowplugin?

Thanks and Regards,
Gobinath



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

Re: [openflowplugin-dev] [genius-dev] [controller-dev] Erratic conversion of packet

[Faseela K]

Hi Ryan,
   Gobinath is seeing that an Action Case set from genius, while it hits 
openflowplugin is converted to a different Action Case. Basically, he is using 
an openflowplugin RPC from Genius as below :

TransmitPacketInput transmitPacketInput = new TransmitPacketInputBuilder()
.setPayload(payload)
.setNode(
new NodeRef(InstanceIdentifier
.builder(Nodes.class)
.child(Node.class,
new NodeKey(new NodeId(
"openflow:" + dpnId)))
.toInstance()))
.setIngress(nodeConnectorRef).setEgress(ref)
.setAction(actions).build();
LOGGER.trace("PacketOut message framed for transmitting {}", 
transmitPacketInput);
return packetProcessingService

The list of actions here has a nicira extension action “Load Register6” which 
is set using “NxActionRegLoadNodesNodeTableFlowApplyActionsCase”..But certain 
random times, by the time this RPC hits Openflowplugin, the action list shows a 
different case “NxActionRegLoadRpcTransmitPacketCase”. Please note that we are 
not hitting this issue always, most of the times the conversion happens 
perfectly fine, during some corner cases alone, we observe this mismatch in 
conversion.
We would like to know whether there is an in-between conversion happening when 
an RPC is invoked, and how it works, and whether such conversion issues are 
expected or not.

Thanks,
Faseela

From: genius-dev-boun...@lists.opendaylight.org 
[mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of Ryan Goulding
Sent: Friday, July 21, 2017 7:54 PM
To: Gobinath . 
Cc: genius-...@lists.opendaylight.org; openflowplugin-dev 

Subject: Re: [genius-dev] [controller-dev] Erratic conversion of packet

+openflowplugin-dev +genius-dev

Regards,

Ryan Goulding

On Fri, Jul 21, 2017 at 3:12 AM, Gobinath . 
> wrote:
Hi,

I’m facing an issue while sending a packetout formed from the “genius” to 
“openflowplugin”.


The ArpUtil module in Genius builds a packet_out message with 
NxActionRegLoadNodesNodeTableFlowApplyActionsCase as action(in genius) but it 
is received at the openflowplugin(ModelDrivenSwitchImpl)

as NxActionRegLoadRpcTransmitPacketCase.



Could anyone throw some light on how this erratic conversion of action case 
could happen.



Thanks and Regards,

Gobinath Suganthan

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

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

Re: [openflowplugin-dev] [genius-dev] [controller-dev] Any takers for liblldp?

[Faseela K]

Genius supports aliveness monitoring of tunnels using lldp(which uses liblldp), 
but as Abhijit indicated this is inturn a payload inside “Openflow packet-out 
message”.

Thanks,
Faseela

From: genius-dev-boun...@lists.opendaylight.org 
[mailto:genius-dev-boun...@lists.opendaylight.org] On Behalf Of Abhijit Kumbhare
Sent: Friday, July 21, 2017 6:07 AM
To: Luis Gomez 
Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org; 
openflowplugin-dev@lists.opendaylight.org; rele...@lists.opendaylight.org; 
Robert Varga ; controller-...@lists.opendaylight.org
Subject: Re: [genius-dev] [openflowplugin-dev] [controller-dev] Any takers for 
liblldp?



I am not sure what this library does but if it is primarily used to process 
LLDP packets, today I do not see any protocol/plugin other than OpenFlow to 
send LLDP frames to controller. For that reason I do not see major issue in 
including this code in openflowplugin. On the other hand if we can replace this 
by an external library, that would be my first choice.


Key question is whether the library can be used by any other means other than 
via OpenFlow. If yes - we should keep it outside. Otherwise - add it to 
OpenFlow Plugin. My understanding is that the code is not specific to OpenFlow 
and can be used as a generic LLDP packet library for constructing/decoding LLDP 
packets - and currently the only mechanism to use it is as a payload in an 
"OpenFlow packet out message". If that is correct - as Robert said - it makes 
sense to keep it as an external library.


On Thu, Jul 20, 2017 at 4:49 PM, Luis Gomez 
> wrote:

> On Jul 20, 2017, at 3:43 PM, Robert Varga > 
> wrote:
>
> On 21/07/17 00:32, Sam Hague wrote:
>> What was the reasoning not to absorb liblldp into the openflow project?
>> Because lldp isn't part of openflow? That makes sense and I don't think
>> we will find a project as this really is it's own protocol.
>
> I do not agree with that -- LLDP is a full-blown protocol, but liblldp
> does not implement the data plane part of it (but hey, anyone could do
> that using liblldp).

I am not sure what this library does but if it is primarily used to process 
LLDP packets, today I do not see any protocol/plugin other than OpenFlow to 
send LLDP frames to controller. For that reason I do not see major issue in 
including this code in openflowplugin. On the other hand if we can replace this 
by an external library, that would be my first choice.

>
>> For the sake of finding a good place to park it, though, ofp is a good
>> project since ofp uses the lib and genius and netvirt use ofp.
>
> I started off with thinking it would better be absorbed, but the mailing
> list discussion made me see the benefit of it being a separate project.
>
>> If not, what was the consensus on if we could reduce the process
>> requirements for making this it's own project? Could we just make the
>> project and let it automatically get pass on the milestones? Make it
>> such that we only have the startup costs to migrate it to a project, get
>> it building and leave it on auto-pilot.
>
> The primary reason is that this is self-contained piece of code, which
> depends on odlparent only and has utterly stable codebase.
>
> Note that odlparent is released independently of autorelease, which
> means so can this project.
>
> That means we only have to build this project once per odlparent release
> (if even necessary), test it once and then reuse it across downstream
> projects. No -SNAPSHOTS involved.
>
> Hence yes, this is a project-on-autopilot. It just needs a caretaker.
>
> That does not preclude it from being a fully active project in the
> future though.
>
> Regards,
> Robert
>
> ___
> controller-dev mailing list
> controller-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-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] [release] [opendaylight-dev] Karaf Status 6/13/2017

[Faseela K]

With Stephen’s patch, odl-genius-ui is not part of bootFeatures in the 
distribution build.
However, the problem is when csit tries to do the same by editing bootFeatures, 
it is not working. I guess there is already a bug for the same.

Feature:install odl-genius-ui works, also if as part of karaf pom.xml we have 
feature listed as karaf.LocalFeature, things work.

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela 
K
Sent: Tuesday, June 20, 2017 2:06 PM
To: Brady Allen Johnson <brady.allen.john...@ericsson.com>; vorbur...@redhat.com
Cc: d...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org; 
rele...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [release] [opendaylight-dev] Karaf Status 
6/13/2017

@Stephen : Thanks for the patch https://git.opendaylight.org/gerrit/#/c/59203/1
This removes odl-genius-ui being part of boot features by default.

Thanks,
Faseela

From: Brady Allen Johnson
Sent: Tuesday, June 20, 2017 1:39 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
vorbur...@redhat.com<mailto:vorbur...@redhat.com>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>;
 d...@lists.opendaylight.org<mailto:d...@lists.opendaylight.org>; 
rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>
Subject: Re: [release] [opendaylight-dev] Karaf Status 6/13/2017


I just reported this bug against the OpenflowPlugin
   https://bugs.opendaylight.org/show_bug.cgi?id=8718

We dont get any of the SFC Nicira Extension flows for NSH (Network Service 
Headers).

This is a major regression for SFC.

Regards,

Brady

-Original Message-
From: Faseela K 
<faseel...@ericsson.com<mailto:faseela%20k%20%3cfaseel...@ericsson.com%3e>>
To: Michael Vorburger 
<vorbur...@redhat.com<mailto:michael%20vorburger%20%3cvorbur...@redhat.com%3e>>
Cc: odl-dev-list 
<d...@lists.opendaylight.org<mailto:odl-dev-list%20%3c...@lists.opendaylight.org%3e>>,
 rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org> 
<rele...@lists.opendaylight.org<mailto:%22rele...@lists.opendaylight.org%22%20%3crele...@lists.opendaylight.org%3e>>
Subject: Re: [release] [opendaylight-dev] Karaf Status 6/13/2017
Date: Tue, 20 Jun 2017 01:39:35 +

Michael,
  Finally I was able to run csit on sandbox with the merge build [0] and it 
passed 100% 
  One thing I had to change was to remove the feature “odl-genius-ui” from the 
csit inputs, because with the new features4-karaf pom.xml for genius, this is 
installed when controller comes up itself, and when the same thing was added as 
part of bootFeatures by the script once again, was getting the below error in 
karaf log [1].

@Michael : I think we should change the genius pom.xml to remove the features 
installed by default.

2017-06-19 23:50:34,097 | ERROR | pool-1-thread-2  | BootFeaturesInstaller  
  | 9 - org.apache.karaf.features.core - 4.0.9 | Error installing boot 
features
org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing 
requirement [root] osgi.identity; osgi.identity=odl-genius-ui; 
type=karaf.feature; version="[0.3.0.SNAPSHOT,0.3.0.SNAPSHOT]"; 
filter:="(&(osgi.identity=odl-genius-ui)(type=karaf.feature)(version>=0.3.0.SNAPSHOT)(version<=0.3.0.SNAPSHOT))"
 [caused by: Unable to resolve odl-genius-ui/0.3.0.SNAPSHOT: missing 
requirement [odl-genius-ui/0.3.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-dluxapps-yangman; type=karaf.feature; 
version="[0.6.0.SNAPSHOT,0.6.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-dluxapps-yangman/0.6.0.SNAPSHOT: missing requirement 
[odl-dluxapps-yangman/0.6.0.SNAPSHOT] osgi.identity; 
osgi.identity=odl-dlux-core; type=karaf.feature; 
version="[0.6.0.SNAPSHOT,0.6.0.SNAPSHOT]" [caused by: Unable to resolve 
odl-dlux-core/0.6.0.SNAPSHOT: missing requirement 
[odl-dlux-core/0.6.0.SNAPSHOT] osgi.identity; 
osgi.identity=org.opendaylight.dlux.loader.implementation; type=osgi.bundle; 
version="[0.6.0.SNAPSHOT,0.6.0.SNAPSHOT]"; resolution:=mandatory [caused by: 
Unable to resolve org.opendaylight.dlux.loader.implementation/0.6.0.SNAPSHOT: 
missing requirement 
[org.opendaylight.dlux.loader.implementation/0.6.0.SNAPSHOT] 
osgi.wiring.package; 
filter:="(&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))"
at 
org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[9:org.apache.karaf.features.core:4.0.9]
at 
org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:389)[9:org.apache.karaf.features.core:4.0.9]
at 
org.apache.felix.resolver.ResolverImpl.resolve(Resolve

Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) genius features, for your local testing

[Faseela K]

Hold on, there are still issues when I built a fresh distribution once again 
with the genius karaf4 patch.
Ports are still not coming up..

Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela 
K
Sent: Thursday, June 15, 2017 8:24 PM
To: Michael Vorburger <vorbur...@redhat.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>; Tomáš Slušný 
<tomas.slu...@pantheon.tech>
Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

Hi Michael,

   With Tomas’ fixes on openflowplugin and openflowjava, I have tested basic 
functionalities of genius karaf4 distribution eg : creating tunnels, and 
configuring l2vlan interfaces etc, and it works fine.
   We will be running whole genius csit, on the distribution now, and report 
issues if any.

Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Wednesday, June 14, 2017 9:41 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 Tomáš Slušný <tomas.slu...@pantheon.tech<mailto:tomas.slu...@pantheon.tech>>
Cc: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

On Wed, Jun 14, 2017 at 5:16 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi,
  Both of your patches are on verify -1 due to SFT failures, are they 
interdependent?

I had a quick look, and both of these failures look very similar to this 
https://lists.opendaylight.org/pipermail/ovsdb-dev/2017-June/004315.html and 
this https://lists.opendaylight.org/pipermail/netvirt-dev/2017-June/004693.html 
stuff - something wrong / missing re the xml:config in features, again. (I 
don't understand why we're suddenly seeing these failures everywhere...)

Tomáš, do you think based on the fixes that went into ovsdb and federation you 
can similarly do the necessary for openflowplugin and openflowjava  as well?
> Do you still want me to test by doing a skipTest?

I suspect that you'd probably hit the same problem that SFT detected, just 
instead of during the build only when you actually install the feature... the 
point of SFT is just to detect it earlier. So the root cause of the these 2 
problems should probably be fixed, first.

Thanks,
Faseela

From: Tomáš Slušný 
[mailto:tomas.slu...@pantheon.tech<mailto:tomas.slu...@pantheon.tech>]
Sent: Wednesday, June 14, 2017 8:15 PM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing


Hi Faseela,



there was some issues with copying initial configuration files in 
OpenFlowPlugin and OpenFlowJava projects, I created patches on gerrit:

* OpenFlowPlugin: https://git.opendaylight.org/gerrit/58956

* OpenFlowJava: https://git.opendaylight.org/gerrit/58955

and opened critical bugs for both of projects on BugZilla here:
* OpenFlowPlugin: https://bugs.opendaylight.org/show_bug.cgi?id=8693
* OpenFlowJava: https://bugs.opendaylight.org/show_bug.cgi?id=8692

This missing initial configuration file in OpenFlowJava was causing that 
SwitchConnectionProvider do not found configuration for it, and so it was not 
started properly, and so it was not listening on any ports. Can you try to test 
it on those 2 patches (or atleast on OpenFlowJava patch, that is the more 
important one) to confirm that it is working for you? I tested this locally and 
on that 2 patches, it was working on Karaf 4 again, ports was opened and 
devices was able to connect.

Regards,
Tomas Slusny
________
Od: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Odoslané: streda, 14. júna 2017 13:43
Komu: Faseela K; openflowplugin-dev
Kópia: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Predmet: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius f

Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) genius features, for your local testing

[Faseela K]

Hi Michael,

   With Tomas’ fixes on openflowplugin and openflowjava, I have tested basic 
functionalities of genius karaf4 distribution eg : creating tunnels, and 
configuring l2vlan interfaces etc, and it works fine.
   We will be running whole genius csit, on the distribution now, and report 
issues if any.

Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Wednesday, June 14, 2017 9:41 PM
To: Faseela K <faseel...@ericsson.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>; Tomáš Slušný 
<tomas.slu...@pantheon.tech>
Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

On Wed, Jun 14, 2017 at 5:16 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi,
  Both of your patches are on verify -1 due to SFT failures, are they 
interdependent?

I had a quick look, and both of these failures look very similar to this 
https://lists.opendaylight.org/pipermail/ovsdb-dev/2017-June/004315.html and 
this https://lists.opendaylight.org/pipermail/netvirt-dev/2017-June/004693.html 
stuff - something wrong / missing re the xml:config in features, again. (I 
don't understand why we're suddenly seeing these failures everywhere...)

Tomáš, do you think based on the fixes that went into ovsdb and federation you 
can similarly do the necessary for openflowplugin and openflowjava  as well?
> Do you still want me to test by doing a skipTest?

I suspect that you'd probably hit the same problem that SFT detected, just 
instead of during the build only when you actually install the feature... the 
point of SFT is just to detect it earlier. So the root cause of the these 2 
problems should probably be fixed, first.

Thanks,
Faseela

From: Tomáš Slušný 
[mailto:tomas.slu...@pantheon.tech<mailto:tomas.slu...@pantheon.tech>]
Sent: Wednesday, June 14, 2017 8:15 PM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing


Hi Faseela,



there was some issues with copying initial configuration files in 
OpenFlowPlugin and OpenFlowJava projects, I created patches on gerrit:

* OpenFlowPlugin: https://git.opendaylight.org/gerrit/58956

* OpenFlowJava: https://git.opendaylight.org/gerrit/58955

and opened critical bugs for both of projects on BugZilla here:
* OpenFlowPlugin: https://bugs.opendaylight.org/show_bug.cgi?id=8693
* OpenFlowJava: https://bugs.opendaylight.org/show_bug.cgi?id=8692

This missing initial configuration file in OpenFlowJava was causing that 
SwitchConnectionProvider do not found configuration for it, and so it was not 
started properly, and so it was not listening on any ports. Can you try to test 
it on those 2 patches (or atleast on OpenFlowJava patch, that is the more 
important one) to confirm that it is working for you? I tested this locally and 
on that 2 patches, it was working on Karaf 4 again, ports was opened and 
devices was able to connect.

Regards,
Tomas Slusny

Od: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Odoslané: streda, 14. júna 2017 13:43
Komu: Faseela K; openflowplugin-dev
Kópia: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Predmet: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

+openflowplugin-dev:
On Wed, Jun 14, 2017 at 1:24 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi Michael,

  Took your patch, built distribution, but openflowplugin ports are not opening 
up on karaf4 distribution, however the same works on karaf3 distribution.

could you raise a new Blocker bug in openflowpluginabout this, and link it to 
https://bugs.opendaylight.org/show_bug.cgi?id=8661 ?   Currently, "officially" 
there "are no blocking problems", and so the Karaf 4 will go ahead as planned.. 
I think it's very important over the coming days to give clear public 
visibility of the situation.

FYI: https://bugs.opendaylight.org/show_bug.cgi?id=8640 was an issue in 
openflowjava, but that one is closed. (And indeed that NPE is gone, I verified; 
so instead of re-opening that, we need a new one.)

Will debug some

Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) genius features, for your local testing

[Faseela K]

Tomas,
   Openflow ports are coming up on the latest karaf4 distribution, we will 
proceed with running our csit now.
Thanks!
Thanks,
Faseela

From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela 
K
Sent: Thursday, June 15, 2017 2:48 PM
To: Tomáš Slušný <tomas.slu...@pantheon.tech>; Michael Vorburger 
<vorbur...@redhat.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>
Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

Thanks Tomas..
I will test and let you know the results.

From: Tomáš Slušný [mailto:tomas.slu...@pantheon.tech]
Sent: Thursday, June 15, 2017 2:26 PM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing


So I updated both patches, and now it should work. In short, dependencies for 
config files was missing from feature's `pom.xml`. Patch on OpenFlowJava was 
already merged, so things should work now for genius.



Regards,

Tomas Slusny


Od: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Odoslané: streda, 14. júna 2017 18:11
Komu: Faseela K; openflowplugin-dev; Tomáš Slušný
Kópia: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Predmet: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

On Wed, Jun 14, 2017 at 5:16 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi,
  Both of your patches are on verify -1 due to SFT failures, are they 
interdependent?

I had a quick look, and both of these failures look very similar to this 
https://lists.opendaylight.org/pipermail/ovsdb-dev/2017-June/004315.html and 
this https://lists.opendaylight.org/pipermail/netvirt-dev/2017-June/004693.html 
stuff - something wrong / missing re the xml:config in features, again. (I 
don't understand why we're suddenly seeing these failures everywhere...)

Tomáš, do you think based on the fixes that went into ovsdb and federation you 
can similarly do the necessary for openflowplugin and openflowjava  as well?
> Do you still want me to test by doing a skipTest?

I suspect that you'd probably hit the same problem that SFT detected, just 
instead of during the build only when you actually install the feature... the 
point of SFT is just to detect it earlier. So the root cause of the these 2 
problems should probably be fixed, first.

Thanks,
Faseela

From: Tomáš Slušný 
[mailto:tomas.slu...@pantheon.tech<mailto:tomas.slu...@pantheon.tech>]
Sent: Wednesday, June 14, 2017 8:15 PM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing


Hi Faseela,



there was some issues with copying initial configuration files in 
OpenFlowPlugin and OpenFlowJava projects, I created patches on gerrit:

* OpenFlowPlugin: https://git.opendaylight.org/gerrit/58956

* OpenFlowJava: https://git.opendaylight.org/gerrit/58955

and opened critical bugs for both of projects on BugZilla here:
* OpenFlowPlugin: https://bugs.opendaylight.org/show_bug.cgi?id=8693
* OpenFlowJava: https://bugs.opendaylight.org/show_bug.cgi?id=8692

This missing initial configuration file in OpenFlowJava was causing that 
SwitchConnectionProvider do not found configuration for it, and so it was not 
started properly, and so it was not listening on any ports. Can you try to test 
it on those 2 patches (or atleast on OpenFlowJava patch, that is the more 
important one) to confirm that it is working for you? I tested this locally and 
on that 2 patches, it was working on Karaf 4 again, ports was opened and 
devices was able to connect.

Regards,
Tomas Slusny
_

Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) genius features, for your local testing

[Faseela K]

Thanks Tomas..
I will test and let you know the results.

From: Tomáš Slušný [mailto:tomas.slu...@pantheon.tech]
Sent: Thursday, June 15, 2017 2:26 PM
To: Michael Vorburger <vorbur...@redhat.com>; Faseela K 
<faseel...@ericsson.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>
Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing


So I updated both patches, and now it should work. In short, dependencies for 
config files was missing from feature's `pom.xml`. Patch on OpenFlowJava was 
already merged, so things should work now for genius.



Regards,

Tomas Slusny


Od: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Odoslané: streda, 14. júna 2017 18:11
Komu: Faseela K; openflowplugin-dev; Tomáš Slušný
Kópia: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Predmet: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

On Wed, Jun 14, 2017 at 5:16 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi,
  Both of your patches are on verify -1 due to SFT failures, are they 
interdependent?

I had a quick look, and both of these failures look very similar to this 
https://lists.opendaylight.org/pipermail/ovsdb-dev/2017-June/004315.html and 
this https://lists.opendaylight.org/pipermail/netvirt-dev/2017-June/004693.html 
stuff - something wrong / missing re the xml:config in features, again. (I 
don't understand why we're suddenly seeing these failures everywhere...)

Tomáš, do you think based on the fixes that went into ovsdb and federation you 
can similarly do the necessary for openflowplugin and openflowjava  as well?
> Do you still want me to test by doing a skipTest?

I suspect that you'd probably hit the same problem that SFT detected, just 
instead of during the build only when you actually install the feature... the 
point of SFT is just to detect it earlier. So the root cause of the these 2 
problems should probably be fixed, first.

Thanks,
Faseela

From: Tomáš Slušný 
[mailto:tomas.slu...@pantheon.tech<mailto:tomas.slu...@pantheon.tech>]
Sent: Wednesday, June 14, 2017 8:15 PM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; 
Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; 
openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>
Cc: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing


Hi Faseela,



there was some issues with copying initial configuration files in 
OpenFlowPlugin and OpenFlowJava projects, I created patches on gerrit:

* OpenFlowPlugin: https://git.opendaylight.org/gerrit/58956

* OpenFlowJava: https://git.opendaylight.org/gerrit/58955

and opened critical bugs for both of projects on BugZilla here:
* OpenFlowPlugin: https://bugs.opendaylight.org/show_bug.cgi?id=8693
* OpenFlowJava: https://bugs.opendaylight.org/show_bug.cgi?id=8692

This missing initial configuration file in OpenFlowJava was causing that 
SwitchConnectionProvider do not found configuration for it, and so it was not 
started properly, and so it was not listening on any ports. Can you try to test 
it on those 2 patches (or atleast on OpenFlowJava patch, that is the more 
important one) to confirm that it is working for you? I tested this locally and 
on that 2 patches, it was working on Karaf 4 again, ports was opened and 
devices was able to connect.

Regards,
Tomas Slusny

Od: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Odoslané: streda, 14. júna 2017 13:43
Komu: Faseela K; openflowplugin-dev
Kópia: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Predmet: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

+openflowplugin-dev:
On Wed, Jun 14, 2017 at 1:24 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi Michael,

  Took your patch, built distribution, but openflowplugin ports are not opening 
up on karaf4 distribution, however the same works on karaf3 distribution.

could you raise a new Blocker bug in openflowpluginabout this, and link it to 
https://bugs.opendaylight.org/show_bug.cgi?id=

Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) genius features, for your local testing

[Faseela K]

Hi,
  Both of your patches are on verify -1 due to SFT failures, are they 
interdependent? Do you still want me to test by doing a skipTest?
Thanks,
Faseela

From: Tomáš Slušný [mailto:tomas.slu...@pantheon.tech]
Sent: Wednesday, June 14, 2017 8:15 PM
To: Michael Vorburger <vorbur...@redhat.com>; Faseela K 
<faseel...@ericsson.com>; openflowplugin-dev 
<openflowplugin-dev@lists.opendaylight.org>
Cc: netvirt-...@lists.opendaylight.org; genius-...@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing


Hi Faseela,



there was some issues with copying initial configuration files in 
OpenFlowPlugin and OpenFlowJava projects, I created patches on gerrit:

* OpenFlowPlugin: https://git.opendaylight.org/gerrit/58956

* OpenFlowJava: https://git.opendaylight.org/gerrit/58955

and opened critical bugs for both of projects on BugZilla here:
* OpenFlowPlugin: https://bugs.opendaylight.org/show_bug.cgi?id=8693
* OpenFlowJava: https://bugs.opendaylight.org/show_bug.cgi?id=8692

This missing initial configuration file in OpenFlowJava was causing that 
SwitchConnectionProvider do not found configuration for it, and so it was not 
started properly, and so it was not listening on any ports. Can you try to test 
it on those 2 patches (or atleast on OpenFlowJava patch, that is the more 
important one) to confirm that it is working for you? I tested this locally and 
on that 2 patches, it was working on Karaf 4 again, ports was opened and 
devices was able to connect.

Regards,
Tomas Slusny

Od: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Odoslané: streda, 14. júna 2017 13:43
Komu: Faseela K; openflowplugin-dev
Kópia: 
netvirt-...@lists.opendaylight.org<mailto:netvirt-...@lists.opendaylight.org>; 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Predmet: Re: [openflowplugin-dev] [genius-dev] Karaf 4 distribution with (just) 
genius features, for your local testing

+openflowplugin-dev:
On Wed, Jun 14, 2017 at 1:24 PM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Hi Michael,

  Took your patch, built distribution, but openflowplugin ports are not opening 
up on karaf4 distribution, however the same works on karaf3 distribution.

could you raise a new Blocker bug in openflowpluginabout this, and link it to 
https://bugs.opendaylight.org/show_bug.cgi?id=8661 ?   Currently, "officially" 
there "are no blocking problems", and so the Karaf 4 will go ahead as planned.. 
I think it's very important over the coming days to give clear public 
visibility of the situation.

FYI: https://bugs.opendaylight.org/show_bug.cgi?id=8640 was an issue in 
openflowjava, but that one is closed. (And indeed that NPE is gone, I verified; 
so instead of re-opening that, we need a new one.)

Will debug some  more and keep you posted.

Thanks,
Faseela

From: 
genius-dev-boun...@lists.opendaylight.org<mailto:genius-dev-boun...@lists.opendaylight.org>
 
[mailto:genius-dev-boun...@lists.opendaylight.org<mailto:genius-dev-boun...@lists.opendaylight.org>]
 On Behalf Of Michael Vorburger
Sent: Monday, June 12, 2017 4:34 PM
To: genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>
Subject: [genius-dev] Karaf 4 distribution with (just) genius features, for 
your local testing

Hello fellow geniusians,
as discussed and committed to during our weekly call last Thursday, I've just 
taken a moment to create https://git.opendaylight.org/gerrit/#/c/58726/ for a 
Karaf 4 distribution with (just) genius features.
Faseela, and others interested, you volunteered during that call to take this 
first genius Karaf 4 distribution for a spin for some local functional testing, 
right? I'm curious what you'll find - basically works just fine? Or completely 
broken? ;-)
Let us use https://bugs.opendaylight.org/show_bug.cgi?id=8661 to record any 
findings (and required actions) in this regard... I suggest you do not overload 
that single bug, but only use it as an "umbrella", and create new linked issues 
for anything you find. I've already done the same for two (very minor) more 
"technical" issues I've noticed when even just starting it up empty.

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


Tomáš Slušný
Software Developer

PANTHEON technologies s.r.o.
Janka Kráľa 9, 974 01 Banská Bystrica
Slovakia
Tel / +421 220 665 111

MAIL / tomas.slu...@pantheon.tech<mailto:tomas.slu...@pantheon.tech>
WEB / https://pantheon.tech


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

Re: [openflowplugin-dev] [genius-dev] Genius Builds Failing

[Faseela K]

Thanks Vratko!
Waiting for this to be merged ☺

Thanks,
Faseela

From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) 
[mailto:vrpo...@cisco.com]
Sent: Thursday, March 02, 2017 8:25 PM
To: Jozef Bacigál <jozef.baci...@pantheon.tech>; Faseela K 
<faseel...@ericsson.com>; Michael Vorburger <vorbur...@redhat.com>
Cc: genius-...@lists.opendaylight.org; 'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org>; rele...@lists.opendaylight.org
Subject: RE: [genius-dev] Genius Builds Failing

https://git.opendaylight.org/gerrit/52664

From: 
release-boun...@lists.opendaylight.org<mailto:release-boun...@lists.opendaylight.org>
 [mailto:release-boun...@lists.opendaylight.org] On Behalf Of Vratko Polak -X 
(vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: 2 March, 2017 15:53
To: Jozef Bacigál 
<jozef.baci...@pantheon.tech<mailto:jozef.baci...@pantheon.tech>>; Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Michael Vorburger 
<vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>
Subject: Re: [release] [genius-dev] Genius Builds Failing

I think I got it, search for
"-Dorg.ops4j.pax.url.mvn.localRepository=/tmp/r "
Yes, it includes space. No, the space should not be there.
Fix is on the way.
Vratko.

From: 
release-boun...@lists.opendaylight.org<mailto:release-boun...@lists.opendaylight.org>
 [mailto:release-boun...@lists.opendaylight.org] On Behalf Of Vratko Polak -X 
(vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: 2 March, 2017 15:28
To: Jozef Bacigál 
<jozef.baci...@pantheon.tech<mailto:jozef.baci...@pantheon.tech>>; Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Michael Vorburger 
<vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>
Subject: Re: [release] [genius-dev] Genius Builds Failing

This happens in distribution-check only,
as that changes maven settings to limit which artifacts are available.
As far as I can tell, odlparent:opendaylight-karaf-empty
is still being downloaded the same way as before.

SFT started failing to see the downloaded zip
somewhere between [0] and [1].
I have no clue what the cause is, yet.

Vratko.

[0] 
https://jenkins.opendaylight.org/releng/view/Distribution-Check/job/cardinal-distribution-check-carbon/68/
[1] 
https://jenkins.opendaylight.org/releng/view/Distribution-Check/job/genius-distribution-check-carbon/1563/

From: 
release-boun...@lists.opendaylight.org<mailto:release-boun...@lists.opendaylight.org>
 [mailto:release-boun...@lists.opendaylight.org] On Behalf Of Jozef Bacigál
Sent: 2 March, 2017 13:24
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Michael 
Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
'openflowplugin-dev' 
<openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>>;
 rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>
Subject: Re: [release] [genius-dev] Genius Builds Failing

+ openflowplugin

Openflowplugin same.

Jozef

From: Faseela K [mailto:faseel...@ericsson.com]
Sent: Thursday, March 2, 2017 12:20 PM
To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>
Subject: Re: [release] [genius-dev] Genius Builds Failing

Saw the same error for couple of patches.
Observed the error in sfc as well.

Thanks,
Faseela

From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Thursday, March 02, 2017 4:33 PM
To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>
Cc: 
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; 
rele...@lists.opendaylight.org<mailto:rele...@lists.opendaylight.org>
Subject: Re: [genius-dev] Genius Builds Failing

On Thu, Mar 2, 2017 at 11:55 AM, Faseela K 
<faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote:
Link to one of the failed jobs :

https://jenkins.opendaylight.org/releng/job/genius-distribution-check-carbon/1570/console

I just ran a "mvn -U clean package" in 

[openflowplugin-dev] Regarding usage of regid match - nicira extension

[Faseela K]

Hi All,
   I am trying to use nicira regid match extension, going through the yang file 
openflowplugin-nicira-extension-match.yang.
   If I have to match on reg value with a mask, how do I achieve that with the 
following yang model?
grouping nxm-nx-reg-grouping {
container nxm-nx-reg {
leaf reg {
type identityref {
base nicira-match:nxm-nx-reg;
}
}
leaf value {
type uint32;
}
}
}

Thanks,
Faseela


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