[openflowplugin-dev] OFP Patches for Magnesium

[Luis Gomez]

FYI, OFP is only missing this patch for magnesium release:

https://git.opendaylight.org/gerrit/c/openflowplugin/+/87961 
<https://git.opendaylight.org/gerrit/c/openflowplugin/+/87961>

I can submit it later today if nobody does before.

BR/Luis


> Begin forwarded message:
> 
> From: D Arunprakash 
> Subject: RE: [openflowplugin-dev] OFP Patches for Magnesium
> Date: February 23, 2020 at 11:10:44 PM PST
> To: "ece...@gmail.com" , openflowplugin-dev 
> 
> 
> Hi Luis,
> There is no other patch which needs to be merged into stable/magnesium.
>
> Regards,
> Arun
> From: openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org> 
>  <mailto:openflowplugin-dev@lists.opendaylight.org>>On Behalf Of Luis Gomez 
> via Lists.Opendaylight.Org <http://lists.opendaylight.org/>
> Sent: Monday, February 24, 2020 2:15 AM
> To: openflowplugin-dev  <mailto:openflowplugin-dev@lists.opendaylight.org>>
> Cc: openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org>
> Subject: [openflowplugin-dev] OFP Patches for Magnesium
>
> Hi OFP devs,
> 
> FYI stable/magnesium branch has been cut (it should be also locked). This 
> means any fix for Magnesium release has to be put in this branch and 
> communicated to Daniel Rosa (Release Manager).
> 
> So far I only see this patch missing: 
> https://protect2.fireeye.com/v1/url?k=e54a378d-b9c39817-e54a7716-0cc47ad93e74-6fb8ea850aa5de74=1=1b5ce70f-528a-46a4-9f00-7c05cde79e19=https%3A%2F%2Fgit.opendaylight.org%2Fgerrit%2Fc%2Fopenflowplugin%2F%2B%2F87522
>  
> <https://protect2.fireeye.com/v1/url?k=e54a378d-b9c39817-e54a7716-0cc47ad93e74-6fb8ea850aa5de74=1=1b5ce70f-528a-46a4-9f00-7c05cde79e19=https%3A%2F%2Fgit.opendaylight.org%2Fgerrit%2Fc%2Fopenflowplugin%2F%2B%2F87522>
>  (merged in stable/sodium)
> 
> Please let me know if there is any more.
> 
> BR/Luis
> 
> 
> 

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

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

[openflowplugin-dev] OFP Patches for Magnesium

[Luis Gomez]

Hi OFP devs,

FYI stable/magnesium branch has been cut (it should be also locked). This means 
any fix for Magnesium release has to be put in this branch and communicated to 
Daniel Rosa (Release Manager).

So far I only see this patch missing: 
https://git.opendaylight.org/gerrit/c/openflowplugin/+/87522 (merged in 
stable/sodium)

Please let me know if there is any more.

BR/Luis


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

View/Reply Online (#8789): 
https://lists.opendaylight.org/g/openflowplugin-dev/message/8789
Mute This Topic: https://lists.opendaylight.org/mt/71497981/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] Openflowplugin Magnesium verify builds are failing with javadoc erros

[Luis Gomez]

Here is a revert patch: 
https://git.opendaylight.org/gerrit/#/c/releng/builder/+/87705/ 



> On Feb 12, 2020, at 10:38 PM, Arunprakash D via Lists.Opendaylight.Org 
>  wrote:
> 
> Changing subject line.
>
> Javadoc failures are observed from Feb 11th and nothing has recently merged 
> in openflowplugin which can cause these failures.
>
> @Róbert Varga , is it possible this might 
> has cause due the 
> patchhttps://git.opendaylight.org/gerrit/#/c/releng/builder/+/86443/ 
>  ?
>
> Regards,
> Arun 
>
> From: openflowplugin-dev@lists.opendaylight.org 
>  
>  > On Behalf Of Somashekhar 
> via Lists.Opendaylight.Org 
> Sent: Thursday, February 13, 2020 12:02 PM
> To: openflowplugin-dev@lists.opendaylight.org 
> 
> Cc: openflowplugin-dev@lists.opendaylight.org 
> 
> Subject: [openflowplugin-dev] FW: Change in openflowplugin[master]: build test
>
> Hi ofp-devs,
>
> The magnesium openflowplugin verify build is failing due to some errors in 
> Javadoc build.
>
> Regards,
> Somashekhar
>
> From: Gerrit Code Review  > 
> Sent: Wednesday, February 12, 2020 10:24 PM
> To: SOMASHEKHAR MANOHARA JAVALAGI  >
> Subject: Change in openflowplugin[master]: build test
>
> Build Failed 
> 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-magnesium-mvn35-openjdk11/243/
>  
> 
>  : FAILURE
> 
> A shell command invoked from Jenkins build has failed, resulting in build 
> being marked as a failure. (
> 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-magnesium-mvn35-openjdk11/243/
>  
> 
>  )
> 
> Logs: 
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-maven-verify-magnesium-mvn35-openjdk11/243
>  
> 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-javadoc-verify-magnesium-openjdk11/181/
>  
> 
>  : SUCCESS
> 
> Logs: 
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-maven-javadoc-verify-magnesium-openjdk11/181
>  
> 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-distribution-check-magnesium/338/
>  
> 
>  : SUCCESS
> 
> Logs: 
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-distribution-check-magnesium/338
>  
> 
> Patch set 1:Verified -1
> 
> View Change 
> 
> To view, visit change 87624 
> .
>  To unsubscribe, 

Re: [openflowplugin-dev] Can't make it today's meeting. Please continue if there is topic to discuss.

[Luis Gomez]

No topic from me, only question is whether we should move issue 
https://jira.opendaylight.org/browse/OPNFLWPLUG-1074 to controller project 
after last comment from Somashekhar.

BR/Luis


> On Jan 27, 2020, at 8:18 AM, Arunprakash D via Lists.Opendaylight.Org 
>  wrote:
> 
> 
> 
> Get Outlook for Android
> 

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

View/Reply Online (#8783): 
https://lists.opendaylight.org/g/openflowplugin-dev/message/8783
Mute This Topic: https://lists.opendaylight.org/mt/70158098/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-dev] Python and RestAPI

[Luis Gomez]

cc-ing OFP list to confirm but I do not think there is a REST API to retrieve 
packet_in messages. Among other things, I think the async behavior of these 
messages would require controller notifications (e.g. websocket).

BR/Luis

> On Dec 10, 2019, at 11:42 PM, Bruno Felippe via Lists.Opendaylight.Org 
>  wrote:
> 
> Hello there. I am new with ODL and I am struggling with Python + Restconf + 
> Packet-In. Is it possible to get packets from the switch to the controller 
> using Restconf or Python? Thanks in advance
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#5719): https://lists.opendaylight.org/g/dev/message/5719
> Mute This Topic: https://lists.opendaylight.org/mt/68147047/1217165
> Group Owner: dev+ow...@lists.opendaylight.org
> Unsubscribe: https://lists.opendaylight.org/g/dev/unsub  [ece...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#8777): 
https://lists.opendaylight.org/g/openflowplugin-dev/message/8777
Mute This Topic: https://lists.opendaylight.org/mt/68154141/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] Pending review

[Luis Gomez]

Thanks Arun :)

> On Nov 21, 2019, at 10:35 PM, D Arunprakash  
> wrote:
> 
> Hi Luis,
> Provided couple of minor comments on these review and also there are open 
> comments on the review. Please address all these and can be merged after that.
> Regards,
> Arun 
> From: openflowplugin-dev@lists.opendaylight.org 
>  On Behalf Of Luis Gomez via 
> Lists.Opendaylight.Org
> Sent: Friday, November 22, 2019 1:47 AM
> To: openflowplugin-dev 
> Cc: openflowplugin-dev@lists.opendaylight.org
> Subject: [openflowplugin-dev] Pending review
>  
> Hi OFP devs,
>  
> We would like to include these 2 patches in next Neon SR3 release:
>  
> https://git.opendaylight.org/gerrit/#/c/openflowplugin/+/85832/ 
> <https://protect2.fireeye.com/v1/url?k=3e067369-628c51a6-3e0633f2-0cc47ad93ea4-1d40d36a6007f882=1=65dbd780-2305-4cea-a76a-04a377c5214d=https%3A%2F%2Fgit.opendaylight.org%2Fgerrit%2F%23%2Fc%2Fopenflowplugin%2F%2B%2F85832%2F>
> https://git.opendayligh t.org/gerrit/#/c/openflowplugin/+/85692/ 
> <https://protect2.fireeye.com/v1/url?k=3daa2196-61200359-3daa610d-0cc47ad93ea4-190c81159a20c4ac=1=65dbd780-2305-4cea-a76a-04a377c5214d=https%3A%2F%2Fgit.opendaylight.org%2Fgerrit%2F%23%2Fc%2Fopenflowplugin%2F%2B%2F85692%2F>
>  
> Please review when you have some time.
>  
> BR/Luis

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

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

[openflowplugin-dev] Pending review

[Luis Gomez]

Hi OFP devs,

We would like to include these 2 patches in next Neon SR3 release:

https://git.opendaylight.org/gerrit/#/c/openflowplugin/+/85832/ 

https://git.opendaylight.org/gerrit/#/c/openflowplugin/+/85692/ 


Please review when you have some time.

BR/Luis

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

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

[openflowplugin-dev] OPNFLWPLUG-1074

[Luis Gomez]

Hi OFP devs,

Just let you know the issue of the table stats is very apparent in master:

https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-sanity-only-magnesium/
 


And it is currently interfering with the patch verification 
(test-openflowplugin-core).

I added some DEBUG logs in the ticket so please take a look when you have some 
time.

BR/Luis

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

View/Reply Online (#8766): 
https://lists.opendaylight.org/g/openflowplugin-dev/message/8766
Mute This Topic: https://lists.opendaylight.org/mt/60972272/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 Discuss] openflowplugin flow removal

[Luis Gomez]

Redirecting to openflowplugin list.

> On Oct 21, 2019, at 2:27 AM, asnake  wrote:
> 
> hello, i am trying to build hybrid flow mode and i want to remove some 
> proactive flow entry from switch based on some criteria, based on statistical 
> usage. How to use, only hint using openflowplugin .
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#8458): 
> https://lists.opendaylight.org/g/Discuss/message/8458
> Mute This Topic: https://lists.opendaylight.org/mt/36313370/1217165
> Group Owner: discuss+ow...@lists.opendaylight.org
> Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub  
> [ece...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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

[openflowplugin-dev] OFP contribution

[Luis Gomez]

Hi OFP devs,

We have a couple of people from Lumina: Deepthi and Ravi, that would like to 
contribute in a regular way to the OFP project. Would it be possible to spend 
some time in the weekly OFP call to go through the code and the existing bugs 
so they can start some contribution?

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

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

[Luis Gomez]

I think in the case of OFP the work can be split in 2:

- Update topology model to last RFC (same as other projects in ODL). To me the 
sooner we can do this the better. This also may have reduced impact in OFP apps 
because the topology model contains very few data (e.g. no specific OFP 
extensions were added to original topology model)

- Migrate OFP inventory to topology. This will be more work and have more 
impact for sure because most (if not all) OFP apps look at the inventory for 
anything to do with OpenFlow. Now I am not sure what is the hurry here because 
inventory model is only used by OFP in ODL so at least there is no ODL 
integration concern AFAICT.

BR/Luis


> On Sep 5, 2019, at 11:19 AM, Robert Varga  wrote:
> 
> [+ 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
> 
> ___
> Discuss mailing list
> disc...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/discuss

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

[openflowplugin-dev] Sodium cluster regression

[Luis Gomez]

The blocker bug I was talking in the TSC call:

https://jira.opendaylight.org/browse/CONTROLLER-1906 


BR/Luis

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

[openflowplugin-dev] Regression detected in Neon

[Luis Gomez]

Hi OFP devs,

FYI a regression has been detected recently in stable/neon branch, see details 
in this ticket:

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


BR/Luis

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

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

[Luis Gomez]

+1

> On May 6, 2019, at 10:57 AM, Anil Vishnoi  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  > 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  >
> Cc: Prasanna Huddar  >, D Arunprakash 
> mailto:d.arunprak...@ericsson.com>>, Shuva Kar 
> mailto:shuva.jyoti.kar...@gmail.com>>, Abhijit 
> Kumbhare mailto:abhijitk...@gmail.com>>, 
> openflowplugin-dev  >
> 
> 
> 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  >; vishnoia...@gmail.com 
> ; Shuva Kar  >
> Cc: Abhijit Kumbhare mailto:abhijitk...@gmail.com>>; 
> openflowplugin-dev  >; 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  > wrote:
> 
> +1
> 
>  
> 
> On 2 May 2019 08:32, Shuva Kar  > wrote:
> 
> +1
> 
>  
> 
> On Thu, 2 May 2019, 08:12 Anil Vishnoi,  > wrote:
> 
> +1
> 
>  
> 
> On Wed, May 1, 2019 at 6:00 PM Anil Vishnoi  > 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

Re: [openflowplugin-dev] [controller-dev] OFP cluster test with "tell-based"

[Luis Gomez]

While waiting for OFP, I have performed other tests with tell-based:

OVSDB seem to be fine with it:

https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-gate-clustering-only-sodium/4/
 
<https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-gate-clustering-only-sodium/4/>
https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-gate-clustering-only-sodium/5/
 
<https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-gate-clustering-only-sodium/5/>

Netconf I do not see any significant change (cluster test is not as stable as 
in OFP or OVSDB):

https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-3node-clustering-only-sodium/20/
 
<https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-3node-clustering-only-sodium/20/>
https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-3node-clustering-only-sodium/21/
 
<https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-3node-clustering-only-sodium/21/>

BR/Luis


> On Feb 26, 2019, at 1:01 PM, Robert Varga  wrote:
> 
> On 26/02/2019 21:52, Luis Gomez wrote:
>> FYI tell-based test with latest master:
>> 
>> https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-3node-gate-clustering-only-sodium/9/
>> 
>> I still see topology link information is not cleared after node/link down in 
>> some random tests.
> 
> There does not seem to be anything out of the ordinary from CDS
> perspective, but there are some OLFE/validation errors.
> 
> Can someone from the OFP team take a look, please?
> 
> Thanks,
> Robert
> 

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

Re: [openflowplugin-dev] [controller-dev] OFP cluster test with "tell-based"

[Luis Gomez]

FYI tell-based test with latest master:

https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-3node-gate-clustering-only-sodium/9/

I still see topology link information is not cleared after node/link down in 
some random tests.

BR/Luis

> On Feb 20, 2019, at 2:35 AM, Robert Varga  wrote:
> 
> On 19/02/2019 19:50, Luis Gomez wrote:
>> 
>> 
>>> On Feb 19, 2019, at 6:16 AM, Robert Varga >> <mailto:n...@hq.sk>> wrote:
>>> 
>>> On 19/02/2019 02:11, Luis Gomez wrote:
>>>> 
>>>> 
>>>>> On Feb 13, 2019, at 2:22 AM, Robert Varga >>>> <mailto:n...@hq.sk>> wrote:
>>>>> 
>>>>> On 12/02/2019 19:44, Luis Gomez wrote:
>>>>>> Hi everybody,
>>>>>> 
>>>>>> FYI I have just tried OFP cluster test with "tell-based" protocol:
>>>>>> 
>>>>>> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-3node-clustering-only-neon/180/robot-plugin/log.html.gz
>>>>>> 
>>>>>> My observations:
>>>>>> 
>>>>>> 1) node/port down events do not clear links in topology, this is
>>>>>> why all topology check test fail.
>>>>> 
>>>>> I think this is related to the transactions not commit in 5 seconds,
>>>>> hence masters are not created.
>>>> 
>>>> Any workaround for this?
>>> 
>>> Not sure... if we have messed up accounding (below), we may end up
>>> reporting things out of whack.
> 
> Alright, we can ditch the builder debugs, as everything there works as
> it is supposed to.
> 
> The reason for non-removal of the links is captured in
> https://logs.opendaylight.org/sandbox/vex-yul-odl-jenkins-2/openflowplugin-csit-3node-clustering-only-sodium/1/odl_3/odl3_karaf.log.gz,
> I think, and it is a VerifyException.
> 
> Filed to https://jira.opendaylight.org/browse/CONTROLLER-1885.
> 
> Regards,
> Robert
> 

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

Re: [openflowplugin-dev] [controller-dev] OFP cluster test with "tell-based"

[Luis Gomez]

> On Feb 19, 2019, at 6:16 AM, Robert Varga  wrote:
> 
> On 19/02/2019 02:11, Luis Gomez wrote:
>> 
>> 
>>> On Feb 13, 2019, at 2:22 AM, Robert Varga  wrote:
>>> 
>>> On 12/02/2019 19:44, Luis Gomez wrote:
>>>> Hi everybody,
>>>> 
>>>> FYI I have just tried OFP cluster test with "tell-based" protocol:
>>>> 
>>>> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-3node-clustering-only-neon/180/robot-plugin/log.html.gz
>>>> 
>>>> My observations:
>>>> 
>>>> 1) node/port down events do not clear links in topology, this is why all 
>>>> topology check test fail.
>>> 
>>> I think this is related to the transactions not commit in 5 seconds,
>>> hence masters are not created.
>> 
>> Any workaround for this?
> 
> Not sure... if we have messed up accounding (below), we may end up
> reporting things out of whack.
> 
>> 
>>> 
>>>> 2) some WARNs are flooding the log:
>>>> 
>>>> 2019-02-12T00:26:30,055 | WARN  | 
>>>> opendaylight-cluster-data-shard-dispatcher-33 | 
>>>> FrontendClientMetadataBuilder| 223 - 
>>>> org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
>>>> member-1-shard-inventory-operational: Unknown history for aborted 
>>>> transaction member-1-datastore-operational-fe-0-txn-30-2, ignoring
>>>> 
>>>> 2019-02-12T00:26:30,056 | WARN  | 
>>>> opendaylight-cluster-data-shard-dispatcher-33 | 
>>>> FrontendClientMetadataBuilder| 223 - 
>>>> org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
>>>> member-1-shard-inventory-operational: Unknown history for aborted 
>>>> transaction member-2-datastore-operational-fe-0-txn-19-1, ignoring
>>>> 
>>>> 2019-02-12T00:26:30,056 | WARN  | 
>>>> opendaylight-cluster-data-shard-dispatcher-33 | 
>>>> FrontendClientMetadataBuilder| 223 - 
>>>> org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
>>>> member-1-shard-inventory-operational: Unknown history for aborted 
>>>> transaction member-3-datastore-operational-fe-0-txn-7-1, ignoring
>>> 
>>> This is interesting, as it starts happening for the same transaction on
>>> all shard members and these are standalone transactions, for which the
>>> history should always be there.
>>> 
>>> Can you re-run the test with debug on
>>> org.opendaylight.controller.cluster.datastore.FrontendClientMetadataBuilder,
>>> please?
>> 
>> Here it is: 
>> https://jenkins.opendaylight.org/sandbox/job/openflowplugin-csit-3node-clustering-only-neon/1
> 
> Thanks, this actually provides a lead: everything works with normal
> transaction chains, yet breaks down with single transactions.
> 
> Since we have module-based shards in play and multi-shard commits, the
> cookie inside LocalHistoryIdentifier becomes significant in lookup --
> and the single history is hard-wired to not have a cookie.
> 
> https://git.opendaylight.org/gerrit/80392 
> <https://git.opendaylight.org/gerrit/80392> does that.

https://jenkins.opendaylight.org/sandbox/job/openflowplugin-csit-3node-clustering-only-sodium/1/
 
<https://jenkins.opendaylight.org/sandbox/job/openflowplugin-csit-3node-clustering-only-sodium/1/>

It looks like the WARNs are addressed, and the only issue remaining is the 
topology update when node/links go down:

> 
> Regards,
> Robert

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

Re: [openflowplugin-dev] [controller-dev] OFP cluster test with "tell-based"

[Luis Gomez]

> On Feb 13, 2019, at 2:22 AM, Robert Varga  wrote:
> 
> On 12/02/2019 19:44, Luis Gomez wrote:
>> Hi everybody,
>> 
>> FYI I have just tried OFP cluster test with "tell-based" protocol:
>> 
>> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-3node-clustering-only-neon/180/robot-plugin/log.html.gz
>> 
>> My observations:
>> 
>> 1) node/port down events do not clear links in topology, this is why all 
>> topology check test fail.
> 
> I think this is related to the transactions not commit in 5 seconds,
> hence masters are not created.

Any workaround for this?

> 
>> 2) some WARNs are flooding the log:
>> 
>> 2019-02-12T00:26:30,055 | WARN  | 
>> opendaylight-cluster-data-shard-dispatcher-33 | 
>> FrontendClientMetadataBuilder| 223 - 
>> org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
>> member-1-shard-inventory-operational: Unknown history for aborted 
>> transaction member-1-datastore-operational-fe-0-txn-30-2, ignoring
>> 
>> 2019-02-12T00:26:30,056 | WARN  | 
>> opendaylight-cluster-data-shard-dispatcher-33 | 
>> FrontendClientMetadataBuilder| 223 - 
>> org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
>> member-1-shard-inventory-operational: Unknown history for aborted 
>> transaction member-2-datastore-operational-fe-0-txn-19-1, ignoring
>> 
>> 2019-02-12T00:26:30,056 | WARN  | 
>> opendaylight-cluster-data-shard-dispatcher-33 | 
>> FrontendClientMetadataBuilder| 223 - 
>> org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
>> member-1-shard-inventory-operational: Unknown history for aborted 
>> transaction member-3-datastore-operational-fe-0-txn-7-1, ignoring
> 
> This is interesting, as it starts happening for the same transaction on
> all shard members and these are standalone transactions, for which the
> history should always be there.
> 
> Can you re-run the test with debug on
> org.opendaylight.controller.cluster.datastore.FrontendClientMetadataBuilder,
> please?

Here it is: 
https://jenkins.opendaylight.org/sandbox/job/openflowplugin-csit-3node-clustering-only-neon/1

> 
>> 3) The cluster perf test does not pass: 
>> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-3node-clustering-perf-bulkomatic-only-neon/180/robot-plugin/log.html.gz
>> 
>> I do not know if we still pursue to switch the cluster protocols, at least 
>> after this test it does not seem an straight forward change.
> 
> I'd like to be able to ditch the old one, but it seems we need to shake
> some bugs out :(
> 
> Thanks,
> Robert
> 

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

[openflowplugin-dev] OFP cluster test with "tell-based"

[Luis Gomez]

Hi everybody,

FYI I have just tried OFP cluster test with "tell-based" protocol:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-3node-clustering-only-neon/180/robot-plugin/log.html.gz

My observations:

1) node/port down events do not clear links in topology, this is why all 
topology check test fail.

2) some WARNs are flooding the log:

2019-02-12T00:26:30,055 | WARN  | opendaylight-cluster-data-shard-dispatcher-33 
| FrontendClientMetadataBuilder| 223 - 
org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
member-1-shard-inventory-operational: Unknown history for aborted transaction 
member-1-datastore-operational-fe-0-txn-30-2, ignoring

2019-02-12T00:26:30,056 | WARN  | opendaylight-cluster-data-shard-dispatcher-33 
| FrontendClientMetadataBuilder| 223 - 
org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
member-1-shard-inventory-operational: Unknown history for aborted transaction 
member-2-datastore-operational-fe-0-txn-19-1, ignoring

2019-02-12T00:26:30,056 | WARN  | opendaylight-cluster-data-shard-dispatcher-33 
| FrontendClientMetadataBuilder| 223 - 
org.opendaylight.controller.sal-distributed-datastore - 1.9.0.SNAPSHOT | 
member-1-shard-inventory-operational: Unknown history for aborted transaction 
member-3-datastore-operational-fe-0-txn-7-1, ignoring

3) The cluster perf test does not pass: 
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/openflowplugin-csit-3node-clustering-perf-bulkomatic-only-neon/180/robot-plugin/log.html.gz

I do not know if we still pursue to switch the cluster protocols, at least 
after this test it does not seem an straight forward change.

BR/Luis

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

Re: [openflowplugin-dev] Regarding OpenFLow Metadata.

[Luis Gomez]

Hi Duraivelan, see my answers below:

> On Dec 18, 2018, at 4:42 AM, Duraivelan Chockalingam  
> wrote:
> 
> Hi 
> I would like to have this clarified, on my question about Metadata
> Let us say, I have an Open Flow rules, as below
>  
> Cookie=0x801, duration=228925.445s, table=17, n_packets=350, 
> n_bytes=32424, priority=10,metadata=0xc000f300/0xff00 
> actions=goto_table:19
>  
> I wanted to understand the following
>  
> I believe these Metadata Values are determined by the ODL

Metadata is a way for a switch to mark a packet and make local routing 
decisions based on that. The flow is programmed by ODL so yes ODL decides the 
metadata.

>  
> Do we have certain rule/ Algorithm , to determine these Metadata from a 
> Packet.
> Because the Actual Packet in OVS is actually switched based on Matching 
> Metadata, Is that correct ??  ( Atleast according to the rule )
>And the Packet itself does not carry the Metadata.

Metadata only exists in the context of the local switch so you cannot for 
instance match an incoming packet using metadata or set a metadata to an 
outgoing packet, but you can for example match a packet, set metadata on it and 
then send the packet to another table for further processing based in metadata. 

>  
> Then how exactly the packet hitting a flow matched against the Metadata.

As explained earlier same switch sets metadata and matches metadata.


> If I understood it correctly the Packets those are traversed between the 
> flow, are within the OVS application itself or Handled @OVS Application 
> level, until it had determined Egress Port
> So in that Case, the MetaData are handled @OVS-Application level, until the 
> Packets is send via Egress Port.

Yes, metadata is only used internally in the switch.

>  
> Finally which Module in ODL is responsible for determine the Metadata, and I 
> would like to understand from the code how exactly it was done.

OpenFlow applications can use or not metadata, if you are interested in the 
topic I would recommend you to reach an application/project that uses metadata 
(e.g. netvirt, SFC, etc) and ask how they use it.

>  
>  
> Thanks for your time, and clarification, and sorry if it is too much.
>  
> ___
> 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] [openflowplugin-users] I have a problem installing of OF-DPA in ODL.

[Luis Gomez]

For l2switch the last supported release is oxygen.

> On Dec 4, 2018, at 1:30 PM, Sam Hague  wrote:
> 
> 
> 
> On Tue, Dec 4, 2018 at 4:15 PM Luis Gomez  <mailto:ece...@gmail.com>> wrote:
> +1, OF-DPA is just an OF agent like any other. Only thing required in 
> controller is to install basic OFP feature 
> odl-openflowplugin-flow-services-rest.
> Maybe keep the "odl-l2switch-all"  feature, as the of-dpa doc was using that 
> feature as well as setting arp config. Try without it first, and then add the 
> feature if things don't look better.
> 
> Check these OFP user guides for reference: 
> https://docs.opendaylight.org/projects/openflowplugin/en/stable-fluorine/users/index.html
>  
> <https://docs.opendaylight.org/projects/openflowplugin/en/stable-fluorine/users/index.html>
> 
> BR/Luis
> 
>> On Dec 4, 2018, at 12:20 PM, Jamo Luhrsen > <mailto:jluhr...@gmail.com>> wrote:
>> 
>> + ofp-dev list
>> 
>> Hi Jake,
>> 
>> I've never played with of-dpa, but some things to try:
>> 
>> - use our newest release which is Fluorine SR1:
>>  https://docs.opendaylight.org/en/stable-fluorine/downloads.html 
>> <https://docs.opendaylight.org/en/stable-fluorine/downloads.html>
>> 
>> - just install openflowplugin. It will bring in anything else it needs,
>>  (e.g. mdsal). I know the website you linked to had a lot of extra
>>  features, but if you just want to see an OF switch connect to ODL,
>>  it should be ok to just install 'odl-openflowplugin-flow-services-rest'
>> 
>> hope it helps
>> 
>> Thanks,
>> JamO
>> 
>> 
>> On 12/4/18 2:10 AM, 김동은 wrote:
>>> Hello, I'm Jake Kim and I am working as a lab intern in Korea University OS 
>>> lab.
>>> I started to learn about SDN just months ago.
>>> I want to install the OF-DPA in ODL, but there are so many errors that  I 
>>> can't understand.
>>> Although I followed the guideline in OF-DPA website, I failed to install 
>>> the main features needed for running OF-DPA in switches. (The web site is 
>>> "http://broadcom-switch.github.io/of-dpa/doc/html/OFDPA_CLIENT_EXAMPLES.html
>>>  
>>> <http://broadcom-switch.github.io/of-dpa/doc/html/OFDPA_CLIENT_EXAMPLES.html>")
>>> Especially whenever I installed the 'odl-mdsal-all', ODL broke down.
>>> And I tried many types of ODL version: Oxygen, Helium etc.
>>> Could I get more information about how to install the OF-DPA in ODL?
>>> Thanks for reading!
>>> ___
>>> openflowplugin-users mailing list
>>> openflowplugin-us...@lists.opendaylight.org 
>>> <mailto:openflowplugin-us...@lists.opendaylight.org>
>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-users 
>>> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-users>
>> ___
>> openflowplugin-dev mailing list
>> openflowplugin-dev@lists.opendaylight.org 
>> <mailto:openflowplugin-dev@lists.opendaylight.org>
>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
>> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev>
> 
> ___
> openflowplugin-users mailing list
> openflowplugin-us...@lists.opendaylight.org 
> <mailto:openflowplugin-us...@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-users 
> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-users>

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

Re: [openflowplugin-dev] [openflowplugin-users] I have a problem installing of OF-DPA in ODL.

[Luis Gomez]

+1, OF-DPA is just an OF agent like any other. Only thing required in 
controller is to install basic OFP feature 
odl-openflowplugin-flow-services-rest.

Check these OFP user guides for reference: 
https://docs.opendaylight.org/projects/openflowplugin/en/stable-fluorine/users/index.html
 


BR/Luis

> On Dec 4, 2018, at 12:20 PM, Jamo Luhrsen  wrote:
> 
> + ofp-dev list
> 
> Hi Jake,
> 
> I've never played with of-dpa, but some things to try:
> 
> - use our newest release which is Fluorine SR1:
>  https://docs.opendaylight.org/en/stable-fluorine/downloads.html
> 
> - just install openflowplugin. It will bring in anything else it needs,
>  (e.g. mdsal). I know the website you linked to had a lot of extra
>  features, but if you just want to see an OF switch connect to ODL,
>  it should be ok to just install 'odl-openflowplugin-flow-services-rest'
> 
> hope it helps
> 
> Thanks,
> JamO
> 
> 
> On 12/4/18 2:10 AM, 김동은 wrote:
>> Hello, I'm Jake Kim and I am working as a lab intern in Korea University OS 
>> lab.
>> I started to learn about SDN just months ago.
>> I want to install the OF-DPA in ODL, but there are so many errors that  I 
>> can't understand.
>> Although I followed the guideline in OF-DPA website, I failed to install the 
>> main features needed for running OF-DPA in switches. (The web site is 
>> "http://broadcom-switch.github.io/of-dpa/doc/html/OFDPA_CLIENT_EXAMPLES.html;)
>> Especially whenever I installed the 'odl-mdsal-all', ODL broke down.
>> And I tried many types of ODL version: Oxygen, Helium etc.
>> Could I get more information about how to install the OF-DPA in ODL?
>> Thanks for reading!
>> ___
>> openflowplugin-users mailing list
>> openflowplugin-us...@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-users
> ___
> 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] fluorine-sr1 respin build is finished and successful

[Luis Gomez]

OFP is also updated now.

> On Nov 18, 2018, at 6:19 AM, Tom Pantelis  wrote:
> 
> 
> 
> On Sun, Nov 18, 2018 at 7:35 AM Ariel Adam  > wrote:
> Hi everyone.
> To complete the Fluorine SR1 #273 sign off process we are still missing 
> inputs for the controller and Openflowplugin.
> Tom, can you take a look at the controller?
> 
> There's 3 tests failing and they've been failing for a while now (as far back 
> as the saved runs). Same tests have been failing in neon too but not in 
> Oxygen. I don't know why off the top of my head - I'll have to take some time 
> to study what the tests do etc.  But this is related to basic functionality 
> (RPCs) and there's been no real changes in quite a while (especially since 
> Fluorine release)  so I suspect it's something with the tests. Maybe Luis or 
> Jamo know more about the history... I set them to IGNORE (for now at least)
> 
>  
> Luis/Anil, can you take a look at the Openflowplugin?
> Let's close this release since we are already super late. 
> 
> Thanks. 
> 
> 
> On Thu, Nov 15, 2018 at 6:51 PM Jamo Luhrsen  > wrote:
> 
> 
> On 11/15/18 8:44 AM, Jamo Luhrsen wrote:
> > 
> > 
> > On 11/15/18 7:55 AM, Robert Varga wrote:
> >> On 15/11/2018 14:43, Sam Hague wrote:
> >>> The fluorine-sr1 respin is finished. What is left to promote it? Do we
> >>> need to redo the test signoff or can the previous stand? The only
> >>> patches were the netvirt one and the distro-check. Netvirt is isolated
> >>> to just netvirt so it is good.
> >>
> >> Oh man, it would have been good to know that a respin is happening --
> >> https://git.opendaylight.org/gerrit/1 
> >>  is a no-brainer to include.
> >>
> >> A respin requires a re-signoff, just in case the test runs found
> >> something the previous one did not, methinks.
> > 
> > I agree.
> 
> the list of jobs to sign-off is smaller this time. I created a new
> tab "SR1-respin1 Status":
> 
> https://docs.google.com/spreadsheets/d/1wtT78KigRQdRi3Gj--jOJJPI7tC4tIi5brmW01vvCsg/edit#gid=932344730
>  
> 
> 
> those results are from this distro-test:
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/integration-distribution-test-fluorine/273
>  
> 
> 
> which used this distribution:
> https://nexus.opendaylight.org/content/repositories//autorelease-2491/org/opendaylight/integration/karaf/0.9.1/karaf-0.9.1.zip
>  
> 
> 
> Thanks,
> JamO
> 
> >> Regards,
> >> Robert
> >>
> >>
> >> ___
> >> 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 
> 
> ___
> 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] OFP CSIT failing

[Luis Gomez]

It turns out I did not neglect anything, it is genuine bug so I remove it for 
now:

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


Ticket open to OFP:

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


BR/Luis

> On Nov 16, 2018, at 2:45 AM, Michael Vorburger  wrote:
> 
> Hello OpenFlowPlugin & CSIT maintaining people,
> 
> The "Check No Network Operational Information After Follower Node2 Restart" & 
> the "Check No Network Operational Information After Leader Restart" CSIT 
> tests on 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-3node-gate-clustering-bulkomatic-only-neon/18/robot/
>  
> 
>  are the only 2 CSIT tests, among hundreds in openflowplugin, which appear to 
> constantly fail on any Gerrit which we "test-openflowplugin-core".
> 
> Would anyone be willing to de-activate those, until someone fixes them?
> 
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com  | IRC: vorburger @freenode 
> | ~ = http://vorburger.ch 
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] OFP CSIT failing

[Luis Gomez]

This is known test issue I patched recently but I may have neglected some 
suite. Patch is coming...

> On Nov 16, 2018, at 2:45 AM, Michael Vorburger  wrote:
> 
> Hello OpenFlowPlugin & CSIT maintaining people,
> 
> The "Check No Network Operational Information After Follower Node2 Restart" & 
> the "Check No Network Operational Information After Leader Restart" CSIT 
> tests on 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-3node-gate-clustering-bulkomatic-only-neon/18/robot/
>  
> 
>  are the only 2 CSIT tests, among hundreds in openflowplugin, which appear to 
> constantly fail on any Gerrit which we "test-openflowplugin-core".
> 
> Would anyone be willing to de-activate those, until someone fixes them?
> 
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com  | IRC: vorburger @freenode 
> | ~ = http://vorburger.ch 
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] c/76588: make ConfigurationServiceFactoryImpl independent of OSGi

[Luis Gomez]

> On Oct 11, 2018, at 3:33 AM, Michael Vorburger  wrote:
> 
> On Tue, Oct 9, 2018 at 9:55 PM Michael Vorburger  > wrote:
> On Tue, Oct 9, 2018 at 9:37 PM Anil Vishnoi  > wrote:
> Now you considered us "Esteemed" (rightfully :P), so i am forced to review it 
> today by the end of the day. ;-)
> 
> I'll do (almost) anything to get stuf merged... ;-)
> 
> CSIT on this one passed successfully - merge 
> https://git.opendaylight.org/gerrit/#/c/76588/ 
>  now? Tx!
> 
> BTW I have a related question... this c/76588 is the first step of possibly a 
> few more adjustments needed - is there anyone reading this who would be 
> willing to work more closely together with me to get OpenFlowplugin fully 
> working as part of https://github.com/vorburger/opendaylight-simple/ 
>  over the coming weeks? 
> I'm a bit nebulous on the internals of OFP. Also, do you guys have CSITs 
> which one of you could run this "simple" distribution against to check it 
> out? 

Is there a link for the simple distribution artifact?

>  
> On Tue, Oct 9, 2018 at 12:33 PM Michael Vorburger  > wrote:
> Esteemed OpenFlowPlugin committers,
> 
> would you consider reviewing and perhaps merging 
> https://git.opendaylight.org/gerrit/#/c/76588/ 
>  ?
> 
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com  | IRC: vorburger @freenode 
> | ~ = http://vorburger.ch 
> 
> -- 
> 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

Re: [openflowplugin-dev] [infrautils-dev] OFP does not build in stable/fluorine

[Luis Gomez]

It may be intermittent, I just pushed another build to double-check.

> On Aug 28, 2018, at 3:08 PM, Michael Vorburger  wrote:
> 
> On Tue, Aug 28, 2018 at 11:13 PM Anil Vishnoi  <mailto:vishnoia...@gmail.com>> wrote:
> Take that back, it's cherry-pick is not really merged in fluorine, so it's 
> something else.
> 
> yeah, some changes related to diagstatus went into master and stably/oxygen, 
> but indeed the stable/fluorine cherry-picks are not yet merged. This is 
> probably a completely unrelated separate new issue - that 
> "IllegalStateException: This connector server is not attached to an MBean 
> server" is new, to me. But is this intermittent or reproducible? Latest 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/241/
>  
> <https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/241/>
>  seems to have passed. The #240 failed in SFT - due to this? Is it locally 
> reproducible?
> 
> Let's track, and further analyse, this as 
> https://jira.opendaylight.org/browse/INFRAUTILS-49 
> <https://jira.opendaylight.org/browse/INFRAUTILS-49> ...
> 
> 
> On Tue, Aug 28, 2018 at 2:11 PM Anil Vishnoi  <mailto:vishnoia...@gmail.com>> wrote:
> Seems like this API change in infrautil is causing the issue 
> 
> https://git.opendaylight.org/gerrit/#/c/75393/ 
> <https://git.opendaylight.org/gerrit/#/c/75393/>
> 
> On Tue, Aug 28, 2018 at 1:35 PM Luis Gomez  <mailto:ece...@gmail.com>> wrote:
> At least this is what this jenkins job shows:
> 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/
>  
> <https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/>
> 
> Below is the exception trace pointing to diagstatus app, any idea what is 
> going on?
> 
> Tests in error: 
>   diag failed; some bundles failed to start
> diag: Failure {Installed=0, Resolved=4, Unknown=0, GracePeriod=7, Waiting=0, 
> Starting=0, Active=305, Stopping=0, Failure=1}
> 1. NOK org.opendaylight.infrautils.diagstatus-impl:1.4.0.SNAPSHOT: OSGi state 
> = Active, Karaf bundleState = Failure, due to: Blueprint
> 8/28/18 8:06 PM
> Exception: 
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when 
> instantiating bean diagStatusServiceMBeanImpl of class 
> org.opendaylight.infrautils.diagstatus.internal.DiagStatusServiceMBeanImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException: 
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when 
> instantiating bean diagStatusServiceMBeanImpl of class 
> org.opendaylight.infrautils.diagstatus.internal.DiagStatusServiceMBeanImpl
> at 
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at 
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at 
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at 
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at 
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at 
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:704)
> at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:410)
> at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:275)
> at 
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at 
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at 
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at 
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at 
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at 
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at 
> org.apache.aries.

[openflowplugin-dev] OFP does not build in stable/fluorine

[Luis Gomez]

At least this is what this jenkins job shows:

https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn35-openjdk8/

Below is the exception trace pointing to diagstatus app, any idea what is going 
on?

Tests in error: 
  diag failed; some bundles failed to start
diag: Failure {Installed=0, Resolved=4, Unknown=0, GracePeriod=7, Waiting=0, 
Starting=0, Active=305, Stopping=0, Failure=1}
1. NOK org.opendaylight.infrautils.diagstatus-impl:1.4.0.SNAPSHOT: OSGi state = 
Active, Karaf bundleState = Failure, due to: Blueprint
8/28/18 8:06 PM
Exception: 
org.osgi.service.blueprint.container.ComponentDefinitionException: Error when 
instantiating bean diagStatusServiceMBeanImpl of class 
org.opendaylight.infrautils.diagstatus.internal.DiagStatusServiceMBeanImpl
org.osgi.service.blueprint.container.ComponentDefinitionException: 
org.osgi.service.blueprint.container.ComponentDefinitionException: Error when 
instantiating bean diagStatusServiceMBeanImpl of class 
org.opendaylight.infrautils.diagstatus.internal.DiagStatusServiceMBeanImpl
at 
org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
at 
org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
at 
org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
at 
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
at 
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
at 
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:704)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:410)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:275)
at 
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
at 
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
at 
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
at 
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
at 
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:239)
at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1298)
at 
org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1278)
at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:236)
at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:194)
at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120)
at 
org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112)
at 
org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168)
at org.eclipse.osgi.container.Module.publishEvent(Module.java:476)
at org.eclipse.osgi.container.Module.start(Module.java:467)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:402)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1361)
at 
org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:894)
at 
org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1248)
at 

[openflowplugin-dev] Update OFP docs

[Luis Gomez]

Hi ofp devs,

I have full updated the OFP user docs and copied the devs docs in docs repo to 
the ofp repo:

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


Please review the changes.

BR/Luis

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

Re: [openflowplugin-dev] Updated to 0.6.2 but nobody listening on port 6653 !

[Luis Gomez]

Not sure which distribution you are using but you can check 
etc/org.apache.karaf.features.cfg to see what is being installed when you start 
it.

> On Aug 4, 2018, at 7:06 PM, M. Ranganathan  wrote:
> 
> Still no luck. Here is my list of openflow features (after the change you 
> suggested ):
> 
> odl-openflowplugin-app-forwardingrules-manager  │ 0.6.2│  
> │ Started │ odl-openflowplugin-app-forwardingrules-manager  │ 
> OpenDaylight :: Openflow Plugin :: Application -
> odl-openflowplugin-libraries│ 0.6.2│  
> │ Started │ odl-openflowplugin-libraries│ 
> OpenDaylight :: Openflow Plugin :: Libraries
> odl-openflowplugin-app-config-pusher│ 0.6.2│  
> │ Started │ odl-openflowplugin-app-config-pusher│ 
> OpenDaylight :: Openflow Plugin :: Application -
> odl-openflowplugin-nsf-model│ 0.6.2│  
> │ Started │ odl-openflowplugin-nsf-model│ 
> OpenDaylight :: OpenflowPlugin :: NSF :: Model
> odl-openflowjava-protocol   │ 0.6.2│  
> │ Started │ odl-openflowjava-0.6.2  │ ODL :: 
> openflowjava :: odl-openflowjava-protocol
> odl-openflowplugin-app-topology │ 0.6.2│  
> │ Started │ odl-openflowplugin-app-topology │ 
> OpenDaylight :: Openflow Plugin :: Application -
> odl-openflowplugin-flow-services│ 0.6.2│  
> │ Started │ odl-openflowplugin-flow-services│ 
> OpenDaylight :: Openflow Plugin :: Flow Services
> odl-openflowplugin-southbound   │ 0.6.2│  
> │ Started │ openflowplugin-0.6.2│ 
> OpenDaylight :: Openflow Plugin :: Li southbound
> odl-openflowplugin-app-reconciliation-framework │ 0.6.2│  
> │ Started │ odl-openflowplugin-app-reconciliation-framework │ 
> OpenDaylight :: Openflow Plugin :: Application -
> 
> 
> I still don't understand one thing -- why is the port being used BEFORE I 
> start my application?
> It appears that the openflow features are already running when the container 
> is started. Indeed when I do a feature list BEFORE starting my own feature I 
> get the SAME list as above. (i.e. the features are in the started state 
> already).
> 
> This is different from my previous version (i.e. Nitrogen ) where these 
> features where listed in an Uninstalled state. 
> 
> Thanks,
> 
> Ranga
> 
> On Sat, Aug 4, 2018 at 7:42 PM, Luis Gomez  <mailto:ece...@gmail.com>> wrote:
> This dependency breaks your feature:
> 
> 
> org.opendaylight.openflowplugin
> features-openflowplugin
> xml
> features
> 
> 
> 
> With the above you are installing all features available in openflowplugin 
> and some of them are not compatible with each other, so instead of bringing 
> the full repo just bring one by one the features (odl-openflowplugin-*) that 
> you need, for example:
> 
> 
> org.opendaylight.openflowplugin
> odl-openflowplugin-southbound
> xml
> features
> 
> 
> BR/Luis
> 
> > On Aug 4, 2018, at 3:41 PM, M. Ranganathan  > <mailto:mra...@gmail.com>> wrote:
> > 
> > 
> 
> 
> 
> 
> -- 
> M. Ranganathan 
> 

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

Re: [openflowplugin-dev] Updated to 0.6.2 but nobody listening on port 6653 !

[Luis Gomez]

This dependency breaks your feature:


org.opendaylight.openflowplugin
features-openflowplugin
xml
features



With the above you are installing all features available in openflowplugin and 
some of them are not compatible with each other, so instead of bringing the 
full repo just bring one by one the features (odl-openflowplugin-*) that you 
need, for example:


org.opendaylight.openflowplugin
odl-openflowplugin-southbound
xml
features


BR/Luis

> On Aug 4, 2018, at 3:41 PM, M. Ranganathan  wrote:
> 
> 

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

Re: [openflowplugin-dev] Updated to 0.6.2 but nobody listening on port 6653 !

[Luis Gomez]

version seems fine, can you tell which ODL features do you install together? 
e.g. output of feature:list -i

BR/Luis

> On Aug 4, 2018, at 12:54 PM, M. Ranganathan  wrote:
> 
> Here are my version settings in my pom.xml file:
> 
> 
>  OpenDaylight :: baseapp :: Impl [Karaf Feature]
>
> 0.12.2
> 1.7.2
> 1.7.2
> 0.7.2
> 0.7.2
> 0.7.2
> 0.4.2
> 0.6.2
> etc/opendaylight/karaf
> 
> 
> I see some exceptions in my log like this:
> 
> 
> Caused by: java.lang.NoSuchMethodException: 
> org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.openflowplugin.app.reconciliation.service.rev180227.ReconciliationService.reconcileNode(org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.openflowplugin.app.reconciliation.service.rev180227.ReconcileNodeInput)
> at java.lang.Class.getMethod(Class.java:1786) ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.BindingToNormalizedNodeCodec.findRpcMethod(BindingToNormalizedNodeCodec.java:333)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.BindingToNormalizedNodeCodec.getRpcMethodToSchema(BindingToNormalizedNodeCodec.java:299)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.RpcServiceAdapter.(RpcServiceAdapter.java:60)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcServiceAdapter.createProxy(BindingDOMRpcServiceAdapter.java:57)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcServiceAdapter.access$000(BindingDOMRpcServiceAdapter.java:24)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcServiceAdapter$1.load(BindingDOMRpcServiceAdapter.java:34)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcServiceAdapter$1.load(BindingDOMRpcServiceAdapter.java:30)
>  ~[?:?]
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3523)
>  ~[?:?]
> at 
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2249) 
> ~[?:?]
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2132)
>  ~[?:?]
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045) 
> ~[?:?]
> at com.google.common.cache.LocalCache.get(LocalCache.java:3962) ~[?:?]
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3966) 
> ~[?:?]
> at 
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4951)
>  ~[?:?]
> at 
> com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4957)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcServiceAdapter.getRpcService(BindingDOMRpcServiceAdapter.java:51)
>  ~[?:?]
> at 
> org.opendaylight.controller.md.sal.binding.compat.HeliumRpcProviderRegistry.getRpcService(HeliumRpcProviderRegistry.java:48)
>  ~[?:?]
> at Proxy9b50ced3_18c2_46fa_ad81_779f5f28b872.getRpcService(Unknown 
> Source) ~[?:?]
> at 
> org.opendaylight.controller.blueprint.ext.AbstractInvokableServiceMetadata.create(AbstractInvokableSe
> 
> 
> Something tells me there's a version mismatch but what?
> 
> Thanks,
> 
> Ranga
> 
> 
> 
> On Sat, Aug 4, 2018 at 3:19 PM, M. Ranganathan  > wrote:
> Hello,
> 
> I recently upgraded to the latest version of openflow plugin. I started my 
> karaf container and I noticed that openflow plugin was already running  when 
> I did a feature:list ( why ? ), I did a netstat and noted port 6653 open as 
> expected. I loaded my application ( which includes openflow plugin features 
> in its feature description ). I did a netstat again and noticed nothing was 
> listening on port 6653. However, when did feature:list the openflow plugin 
> feature was still running.
> 
> I am looking for clues about what could be happening. Any help debugging this 
> would be appreciated.
> 
> Note that this same application was running fine under Nitrogen. 
> 
> I'd be glad to attach Karaf logs if anybody could help.
> 
> Thank you in advance.
> 
> Ranga
> 
> -- 
> M. Ranganathan 
> 
> 
> 
> 
> -- 
> 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] [All channel inactive]Switch concurrency connect to odl and all others switch disconnected problem

[Luis Gomez]

The message below indicates the switch disconnects, since this is OVS, can you 
check in the OVS log (e.g. ovs-vswitchd.log) the reason for the disconnect? If 
the reason is timeout receiving echo response from controller, this means 
controller is too busy to respond to switch echos in which case switch 
disconnects and reconnects back making things worse. If that is the problem can 
you try the same scenario after setting the OVS inactivity_probe parameter to 0?


> On Jul 30, 2018, at 6:42 AM, 陈卓文  wrote:
> 
> 2018-07-24T20:55:00,333 | INFO  | epollEventLoopGroup-9-42 | 
> SystemNotificationsListenerImpl  | 326 - org.opendaylight.openflowplugin.impl 
> - 0.6.2.netease1 | ConnectionEvent: Connection closed by device, 
> Device:/:35922, NodeId:openflow:xxx

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

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

[Luis Gomez]

This is a known issue of current FRM, see ticket below:

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


AFAIK work is in progress but no merge yet.

BR/Luis


> On Jul 16, 2018, at 9:43 AM, Vishal Thapar  wrote:
> 
> Greetings OFP Devs,
> 
> We're seeing an issue in Netvirt CSIT. The failure has been root caused to a 
> missing flow and from OVS logs [1] we can see the reason being flow is added 
> before the group.
> 
> 2018-07-15T03:42:58.872Z|09648|vconn|DBG|tcp:10.30.170.132:6653 
> : received: OFPT_FLOW_MOD (OF1.3) (xid=0x1142): 
> ADD table:26 priority=5,ip,metadata=0x30d78/0xfe cookie:0x806 
> actions=set_field:0x186bc->tun_id,group:225006
> 2018-07-15T03:42:58.872Z|09649|connmgr|INFO|br-int<->tcp:10.30.170.132:6653 
> : sending OFPBAC_BAD_OUT_GROUP error reply to 
> OFPT_FLOW_MOD message
> 2018-07-15T03:42:58.872Z|09650|vconn|DBG|tcp:10.30.170.132:6653 
> : sent (Success): OFPT_ERROR (OF1.3) 
> (xid=0x1142): OFPBAC_BAD_OUT_GROUP
> OFPT_FLOW_MOD (OF1.3) (xid=0x1142):
> (***truncated to 64 bytes from 112***)
>   04 0e 00 70 00 00 11 42-00 00 00 00 08 00 00 06 |...p...B|
> 0010  00 00 00 00 00 00 00 00-1a 00 00 00 00 00 00 05 ||
> 0020  ff ff ff ff ff ff ff ff-ff ff ff ff 00 00 00 00 ||
> 0030  00 01 00 1e 80 00 05 10-00 00 00 00 00 03 0d 78 |...x|
> 2018-07-15T03:42:58.872Z|09651|vconn|DBG|tcp:10.30.170.132:6653 
> : received: OFPT_GROUP_MOD (OF1.3) (xid=0x1143):
>  ADD 
> group_id=225006,type=all,bucket=actions=load:0x300->NXM_NX_REG6[],resubmit(,220)
> 
> 
> Wasn't there some feature/fix done in OFP to ensure groups were always added 
> before a flow? Or was that only for resync use case? Am I misremembering a 
> feature that was never implemented or is this a bug?
> 
> Regards,
> Vishal.
> 
> [1] 
> https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/netvirt-csit-1node-openstack-queens-upstream-stateful-snat-conntrack-oxygen/329/compute_2/ovs-vswitchd.log.gz
>  
> 
> 
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

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

Re: [openflowplugin-dev] Sending flow to switch but NOT the config database?

[Luis Gomez]

You can send openflow RPC like the example below:

POST http://192.168.0.101:8181/restconf/operations/sal-flow:add-flow
{
"input": {
  
"opendaylight-flow-service:node":"/opendaylight-inventory:nodes/opendaylight-inventory:node[opendaylight-inventory:id='openflow:1']",
  "priority": 2,
  "flow-name": "flow1",
  "table_id": 0,
  "hard-timeout": 0,
  "instructions": {
"instruction": [
  {
"order": 0,
"apply-actions": {
  "action": [
{
  "order": 0,
  "output-action": {
"output-node-connector": "1"
  }
}
  ]
}
  }
]
  },
  "idle-timeout": 0,
  "match": {
"ipv4-destination": "10.0.10.0/24",
"ethernet-match": {
  "ethernet-type": {
"type": 2048
  }
}
  }
}
}



> On Jul 12, 2018, at 12:09 PM, M. Ranganathan  wrote:
> 
> I am using OpendDaylight Nitrogen. In order to send a flow to the switch, I 
> write to the CONFIG database - which winds up sending the flow to the switch. 
> However, I want faster performance for ephemeral flows . How can I send the 
> flow to the switch without involving the CONFIG database?
> 
> Thanks,
> 
> Ranga
> 
> -- 
> 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] Sporadic failure in pushing flows to switch

[Luis Gomez]

> I do see plenty of role change
> messages in kraf logs

Any idea why these role change requests? is OVS disconnecting/reconnecting for 
some reason (e.g. echo not answered)? or do you see any controller/cluster 
condition triggering these role changes?

> On May 31, 2018, at 11:20 PM, Vishal Thapar  wrote:
> 
> Reminder. I can raise a Jira and share the logs but need to know which 
> debugs/trace to enable to catch relevant information. Basic INFO don't show 
> anything.
> 
> On Thu, May 31, 2018 at 11:36 AM, Vishal Thapar  > wrote:
> Hi OFP Devs,
> 
> I'm seeing a sporadic issue locally where table miss flows for some of
> the tables are not pushed to OVS even though they're present in config
> DS. It happens only in 3 node setup and I do see plenty of role change
> messages in kraf logs. Note these log change messages show up for
> other computes too, not just the ones on which I see the issue.
> 
> Any inputs on what could be the reason? Any logging I can enable to
> help troubleshoot? I can raise a bug for this but need to know what
> information to capture. Note that restarting OVS or the compute does
> bring back the missing flows, but it is not a practical workaround.
> 
> Thanks and Regards,
> Vishal.
> 
> ___
> 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] [OpenDaylight Discuss] unable to contact remote controller

[Luis Gomez]

And also what does it mean "installed All odl-openflowplugin features"? that 
most likely will fail the installation.

Please see this thread:

https://lists.opendaylight.org/pipermail/openflowplugin-dev/2018-April/008188.html
 


BR/Luis


> On May 25, 2018, at 11:20 AM, Jamo Luhrsen  wrote:
> 
> I changed this from the discuss list to the ofp list.
> 
> some things to check:
> 
> - is port 6633 really up on the ODL VM? (netstat will help check)
> - you can try with port 6653 too. I think that's the standard port now
> - look at the karaf.log for any clues to the problem
> 
> 
> Thanks,
> JamO
> 
> On 5/25/18 2:08 AM, Vidusala Kumari wrote:
>> Hi everyone,
>> I installed ODL oxygen version in Ubuntu 18.05 Desktop VM and Mininet in 
>> Ubuntu 18.04 Server Vm in VirtualBox and also can ping from mininet VM to 
>> ODL VM and vice versa
>> ODL also in running state and installed All odl-openflowplugin features
>> When I run the following topology in mininet it always says unable to 
>> contact remote controller at x.x.x.:6633
>> Can any one help me on this error
>> ___
>> Discuss mailing list
>> disc...@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/discuss
> ___
> 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] [OpenDaylight TSC] OpenFlowplugin Committer Nomination for Arun Prakash

[Luis Gomez]

+1 to Arun becoming committer for openflowplugin.


> On May 24, 2018, at 6: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%2540ericsson.com%22+project:openflowplugin
>  
> 
> [2] 
> https://git.opendaylight.org/gerrit/#/q/project:openflowplugin+reviewedby:%22d.arunprakash%2540ericsson.com%22
>  
> 
> 
> -- 
> 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

Re: [openflowplugin-dev] [opnfv-tech-discuss] Request for Network Administration tools

[Luis Gomez]

The best project we have for controlling OF physical boxes is VTN:

http://docs.opendaylight.org/en/stable-oxygen/user-guide/virtual-tenant-network-(vtn).html
 


Unfortunately this projects has been archived after Oxygen release but you got 
all the contribution in that release:

https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/karaf/0.8.0/
 


BR/Luis


> On May 23, 2018, at 10:18 AM, Jamo Luhrsen  wrote:
> 
> OpenDaylight doesn't have to be coupled with OpenStack.
> 
> I think what you want to do is going to be better answered by the 
> openflowplugin
> project in opendaylight.
> 
> Parker, I'd suggest sending an email to 
> openflowplugin-dev@lists.opendaylight.org
> (actually, I just CC'd them), of which Luis is involved. I think he might even
> have some experience doing some physical switch management with ODL and 
> openflow
> which is what you are looking for.
> 
> Thanks,
> JamO
> 
> On 5/23/18 7:00 AM, Parker Berberian wrote:
>> Hi Mark,
>> I have taken a look at this tool and it is not clear to me that I could use 
>> this to configure the Cisco switches. It seems to have the ability to 
>> collect configuration information and update firmware, but would I be able 
>> to e.g. add a set of ports to a vlan through the REST API?
>> Thank you,
>> Parker
>> On Tue, May 22, 2018 at 10:19 PM, Beierl, Mark > > wrote:
>>Hello, Parker.
>>There is another, non OpenStack project, RackHD, which claims to support 
>> provisioning for Cisco.
>>Here’s a note from one of their devs:
>>Our team worked on cisco support for discovery, FW update and 
>> configuration. Here is the microservice code :
>>https://github.com/RackHD/on-network 
>> 
>>It also has all the workflows hooks in RackHD workflow engine.
>>If you’re interested in exploring that, I can be a point of contact to 
>> see what automation can be done with RackHD.
>>Regards,
>>Mark
>>*Mark Beierl*
>>SW System Sr Principal Engineer
>>*Dell **EMC* | Cloud & Communication Service Provider Solution
>>mobile+1 613 314 8106 
>>mark.bei...@dell.com 
>>On May 22, 2018, at 17:31, MORTON, ALFRED C (AL) > > wrote:
>>>Hi Parker,
>>> 
>>>__ __
>>> 
>>>OPNFV has a controller performance project, CPERF, 
>>> 
>>>which doesn’t participate in releases but continues its work
>>> 
>>>on controller testing. The project is also a resource for 
>>> collaboration
>>> 
>>>between ODL and OPNFV when issues come up.  This sounds like
>>> 
>>>yet another opportunity for collaboration.
>>> 
>>>__ __
>>> 
>>>I’ve CC’d our PTL, Sai, and Daniel, Luis, and Jamo who are
>>> 
>>>other Cperf regulars. Both Jamo and I attended the LaaS
>>> 
>>>presentation you did with Jack at ONS 2018 and asked several 
>>> questions.
>>> 
>>>__ __
>>> 
>>>I’m taking some time off this week, but I’m sure a 
>>> 
>>>Cperf’er can help. We also have a mini-meeting at 
>>> 
>>>2:15pm ET Thursday for more interactive discussions.
>>> 
>>>__ __
>>> 
>>>regards,
>>> 
>>>Al
>>> 
>>>__ __
>>> 
>>>*From:*opnfv-tech-discuss-boun...@lists.opnfv.org 
>>> 
>>>[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org 
>>> ] *On Behalf
>>>Of *Parker Berberian
>>>*Sent:* Friday, May 18, 2018 12:41 PM
>>>*To:* opnfv-tech-disc...@lists.opnfv.org 
>>> 
>>>*Subject:* [opnfv-tech-discuss] Request for Network Administration 
>>> tools
>>> 
>>>__ __
>>> 
>>>Hi All,
>>> 
>>>__ __
>>> 
>>>If you don't know me, I am Parker Berberian. I am running the Lab as a 
>>> Service at the UNH Interoperability Lab.
>>> 
>>>__ __
>>> 
>>>We are beginning development on supporting dynamic pod allocation. To do 
>>> this, we need to be able to manipulate
>>>our underlay network in an automated fashion in order to create opnfv 
>>> "pods" from any arbitrary machines we host.
>>> 
>>>__ __
>>> 
>>>Essentially, when a deployment happens, we need to be able to take any 
>>> of our available machines and add them to
>>>the appropriate vlans and make sure they can all talk to each other. 
>>> There may be as many as 4 switches between
>>>different machines, so all the necessary switches need to be configured 
>>> to forward the given vlans.
>>> 
>>>__ __
>>> 
>>>We use Cisco 9300 

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

[Luis Gomez]

It is correct, the last time I run multi-patch I used the fast format 
(multipatch-build-fast) to verify compilation issues and that passes, now that 
you use the default format that builds with test, openflowplugin exposes a unit 
test problem. I hope someone familiar with this test can take a look.


> On May 14, 2018, at 7:51 PM, Faseela K <faseel...@ericsson.com> wrote:
> 
> 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] [genius-dev] Autorelease build failing while adding dependency on genius-srm from openflowplugin

[Luis Gomez]

For the project extra repo you will have to make the case to the TSC, this is 
explain in detail the issue you have today and how an extra repo would help 
with the same. After that you can get approval (or rejection) from TSC.

> On May 14, 2018, at 10:04 AM, Michael Vorburger <vorbur...@redhat.com> wrote:
> 
> 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 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 <vorbur...@redhat.com 
>> <mailto:vorbur...@redhat.com>> wrote:
>> 
>> On Mon, May 14, 2018 at 1:52 PM, D Arunprakash <d.arunprak...@ericsson.com 
>> <mailto:d.arunprak...@ericsson.com>> wrote:
>> Hello,
>> 
>> We are trying to use the genius service recovery framework(srm-api) from 
>> openflowplugin.
>> 
>> https://git.opendaylight.org/gerrit/#/c/68998/ 
>> <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
>>  
>> <https://jenkins.opendaylight.org/releng/job/openflowplugin-validate-autorelease-fluorine/81/console>
>>  
>> 
>> 09:17:41 + ./scripts/determine-merge-order.py
>> 
>> 09:17:42 Traceback (most recent call last):
>> 
>> 09:17:42   File "./scripts/determine-merge-order.py", line 80, in 
>> 
>> 09:17:42 determine_merge_order()
>> 
>> 09:17:42   File "./scripts/determine-merge-order.py", line 68, in 
>> determine_merge_order
>> 
>> 09:17:42 for d in deps_order:
>> 
>> 09:17:42   File 
>> "/w/workspace/openflowplugin-validate-autorelease-fluorine/venv/lib/python2.7/site-packages/networkx/algorithms/dag.py",
>>  line 197, in topological_sort
>> 
>> 09:17:42 raise nx.NetworkXUnfeasible("Graph contains a cycle or graph 
>> changed "
>> 
>> 09:17:42 networkx.exception.Ne 
>> <http://networkx.exception.ne/>tworkXUnfeasible: Graph contains a cycle or 
>> graph changed during iteration
>> 
>> 09:17:42 Build step 'Execute shell' marked build as failure
>> 
>> 09:17:42 $ ssh-agent -k
>> 
>>  
>> 
>>  
>> 
>> Could you please let us know if the feature exposed from genius is proper or 
>> jenkin autorelease script detect the circular dependency, even though the 
>> odl-genius-srm doesn’t dependent on ofp.
>> 
>> 
>> Arun, yeah you (OFP) should be able to depend on odl-genius-srm now, that's 
>> what all the effort of Moving datastore related utils from mdsalutil to new 
>> "genius.tools" was all about... I just had a look (on latest master) through 
>> genius/srm and genius/features/odl-genius-srm to make sure we didn't forget 
>> anything obvious, but all seems right to me...
>> 
>> integration-dev: could any of you shed light on exactly what the failure 
>> above is trying to tell us - what cycle in the graph has this found?
>> 
>> One thought: Are we allowed to have cycles between projects as long as 
>> artifacts themselves don't have cycles? Because that is what we are doing 
>> here - ofp wants genius.srm which needs genius.tools, which is independant 
>> of the rest of all of genius. genius.mdsalutils and the rest of genius is 
>> dependant on ofp.
>> 
>> Or is that ^^^ is a problem for integration/autorelease? But why? there 
>> isn't really a cycle; and you can build this in a Maven reactor from sources 
>> without requiring binaries. 
>> 
>> Otherwise we have a bigger problem. Resolving that would require an entire 
>> new ODL project. OMG the paperwork... :-(
>

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

[Luis Gomez]

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.


> 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 nx.NetworkXUnfeasible("Graph contains a cycle or graph 
> changed "
> 
> 09:17:42 networkx.exception.NetworkXUnfeasible: Graph contains a cycle or 
> graph changed during iteration
> 
> 09:17:42 Build step 'Execute shell' marked build as failure
> 
> 09:17:42 $ ssh-agent -k
> 
>  
> 
>  
> 
> Could you please let us know if the feature exposed from genius is proper or 
> jenkin autorelease script detect the circular dependency, even though the 
> odl-genius-srm doesn’t dependent on ofp.
> 
> 
> Arun, yeah you (OFP) should be able to depend on odl-genius-srm now, that's 
> what all the effort of Moving datastore related utils from mdsalutil to new 
> "genius.tools" was all about... I just had a look (on latest master) through 
> genius/srm and genius/features/odl-genius-srm to make sure we didn't forget 
> anything obvious, but all seems right to me...
> 
> integration-dev: could any of you shed light on exactly what the failure 
> above is trying to tell us - what cycle in the graph has this found?
> 
> One thought: Are we allowed to have cycles between projects as long as 
> artifacts themselves don't have cycles? Because that is what we are doing 
> here - ofp wants genius.srm which needs genius.tools, which is independant of 
> the rest of all of genius. genius.mdsalutils and the rest of genius is 
> dependant on ofp.
> 
> Or is that ^^^ is a problem for integration/autorelease? But why? there isn't 
> really a cycle; and you can build this in a Maven reactor from sources 
> without requiring binaries. 
> 
> Otherwise we have a bigger problem. Resolving that would require an entire 
> new ODL project. OMG the paperwork... :-(
> 
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com  | IRC: vorburger @freenode 
> | ~ = http://vorburger.ch 
>  
> 
> 
> Regards,
> 
> Arun
> 
> 
> ___
> genius-dev mailing list
> genius-...@lists.opendaylight.org 
> https://lists.opendaylight.org/mailman/listinfo/genius-dev 
> 
> 
> 
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org 
> 
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> 
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

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

[Luis Gomez]

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

https://git.opendaylight.org/gerrit/#/c/66607/ 
<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 <ece...@gmail.com> 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/
>  
> <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 <thanh...@linuxfoundation.org 
>> <mailto:thanh...@linuxfoundation.org>> wrote:
>> 
>> On Sun, Apr 22, 2018 at 8:18 PM, Anil Belur <abe...@linuxfoundation.org 
>> <mailto:abe...@linuxfoundation.org>> wrote:
>> On Mon, Apr 23, 2018 at 9:26 AM, Anil Belur <abe...@linuxfoundation.org 
>> <mailto:abe...@linuxfoundation.org>> 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/
>>  
>> <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
>>  
>> <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
>>  
>> <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 
>> <mailto:openflowplugin-dev@lists.opendaylight.org>
>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
>> <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] Carbon SR4 - stable/carbon branch locked

[Luis Gomez]

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

[Luis Gomez]

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  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]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 
> 
>  
> ___
> integration-dev mailing list
> 

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

[Luis Gomez]

Obviously if the time of fixing the downstream is more than the time of 
reverting the patch we should revisit yesterday’s TSC decision. In this new 
situation I would vote to revert.

BR/Luis


> On Apr 20, 2018, at 8:13 AM, Faseela K <faseel...@ericsson.com> wrote:
> 
> 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 <vorbur...@redhat.com>
> Cc: openflowplugin-dev@lists.opendaylight.org; tsc 
> <t...@lists.opendaylight.org>; mdsal-...@lists.opendaylight.org; Release 
> <rele...@lists.opendaylight.org>; 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 <vorbur...@redhat.com 
> <mailto:vorbur...@redhat.com>> wrote:
>  
> On Thu, Apr 19, 2018 at 9:52 PM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> 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 
> <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 <mailto:vorbur...@redhat.com> | IRC: vorburger @freenode 
> | ~ = http://vorburger.ch <http://vorburger.ch/>
>  
> 
>  
> BR/Luis
>  
> On Apr 19, 2018, at 11:44 AM, Abhijit Kumbhare <abhijitk...@gmail.com 
> <mailto:abhijitk...@gmail.com>> wrote:
>  
> Added the TSC.
>  
> On Thu, Apr 19, 2018 at 11:41 AM, Abhijit Kumbhare <abhijitk...@gmail.com 
> <mailto:abhijitk...@gmail.com>> 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 <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
>  
> On Apr 19, 2018, at 7:16 AM, Tom Pantelis <tompante...@gmail.com 
> <mailto:tompante...@gmail.com>> wrote:
>  
>  
>  
> On Thu, Apr 19, 2018 at 9:14 AM, Vishal Thapar <vtha...@redhat.com 
> <mailto:vtha...@redhat.com>> 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 e

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

[Luis Gomez]

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 
<https://jira.opendaylight.org/browse/TSC-92>

BR/Luis

> On Apr 19, 2018, at 11:44 AM, Abhijit Kumbhare <abhijitk...@gmail.com> wrote:
> 
> Added the TSC.
> 
> On Thu, Apr 19, 2018 at 11:41 AM, Abhijit Kumbhare <abhijitk...@gmail.com 
> <mailto:abhijitk...@gmail.com>> 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 <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> 
>> On Apr 19, 2018, at 7:16 AM, Tom Pantelis <tompante...@gmail.com 
>> <mailto:tompante...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Thu, Apr 19, 2018 at 9:14 AM, Vishal Thapar <vtha...@redhat.com 
>> <mailto:vtha...@redhat.com>> 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 <mailto:mdsal-...@lists.opendaylight.org>
>> https://lists.opendaylight.org/mailman/listinfo/mdsal-dev 
>> <https://lists.opendaylight.org/mailman/listinfo/mdsal-dev>
> 
> 
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> <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] [mdsal-dev] [release] Build breakage in openflowplugin due IP address NoZone changes

[Luis Gomez]

> 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

Re: [openflowplugin-dev] Link information doesn't appear in topology after restart mininet & still get nodes after shutdown mininet

[Luis Gomez]

> On Apr 18, 2018, at 4:59 PM, Mingming Chen <mingmingmi...@126.com> wrote:
> 
> Hi Luis,
> 
> Thank you! You are right! Things went well if I just installed 
> odl-openflowplugin-flow-services-rest 
> odl-openflowplugin-app-table-miss-enforcer. But I still didn't succeed in h1 
> ping h2. Did I make something wrong again?

For ping you need l2switch, which means instead of the 2 mentioned features, 
you can just install: odl-l2swich-switch-rest.

> 
> Another question: Were those problems caused by 
> odl-openflowplugin-app-forwardingrules-sync? I encountered the same problem 
> if I installed forwardingrules-sync besides flow-services-rest and 
> table-miss-enforcer. I thought features-openflowplugin means the integration 
> of openflowplugin individual features.
> Thank you!

Most likely, flow-services-rest installs flow-services-rest that is not 
compatible with odl-openflowplugin-app-forwardingrules-sync.

> 
> Best Regards,
> Mingming
> 
> At 2018-04-19 06:54:04, "Luis Gomez" <ece...@gmail.com> wrote:
> Are you doing feature:install features-openflowplugin? I am asking because 
> that is not right way of instilling features in ODL.
> 
> You have to install individual features, like those you see in this release 
> notes:
> 
> http://docs.opendaylight.org/en/stable-oxygen/release-notes/projects/openflowplugin.html
> 
> Also for basic OF plugin with topology discovery, you can use these 2 
> features:
> 
> odl-openflowplugin-flow-services-rest
> odl-openflowplugin-app-table-miss-enforcer
> 
> BR/Luis
> 
> 
>> On Apr 18, 2018, at 2:19 PM, Mingming Chen <mingmingmi...@126.com> wrote:
>> 
>> Hi,
>> I am working on oxygen-stable. I just installed features-openflowplugin. By 
>> the way, port 6633 will not being listening if I installed both 
>> features-openflowplugin and features-l2switch. Thank you!
>> 
>> At 2018-04-19 04:10:53, "Luis Gomez" <ece...@gmail.com> wrote:
>> This is odd, it seems the topology does not get discovered whenever mininet 
>> gets restarted, can you tell which version of ODL and which features are you 
>> installing?
>> 
>>> On Apr 18, 2018, at 12:22 PM, Mingming Chen <mingmingmi...@126.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I have done some experiment on getting link information of topology. I hope 
>>> it could be helpful. It seems like openflowplugin has sync problem of 
>>> operational data store. We can see that mininet restart could cause missing 
>>> link information problems even though links should be shown. If that is 
>>> operational data store's sync problem, it could explain why I still get 
>>> nodes from operational data store after I shutdown mininet.
>>> Link Information Testing on openflowplugin 
>>> Experiment No. 
>>> First startup 
>>> Second startup 
>>> Restart 
>>> Result 
>>> 1 
>>> openflowplugin 
>>> mininet 
>>>  
>>> success 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>> 2 
>>> openflowplugin 
>>> mininet 
>>>  
>>> success 
>>>  
>>>  
>>>  
>>> openflowplugin 
>>> success 
>>>  
>>>  
>>>  
>>> openflowplugin 
>>> success 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>>  
>>>  
>>>  
>>> openflowplugin 
>>> success 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>> 3 
>>> mininet 
>>> openflowplugin 
>>>  
>>> success 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>>  
>>>  
>>>  
>>> openflowplugin 
>>> success 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>> 4 
>>> mininet 
>>> openflowplugin 
>>>  
>>> success 
>>>  
>>>  
>>>  
>>> openflowplugin 
>>> success 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>>  
>>>  
>>>  
>>> mininet 
>>> failure 
>>> "failure" means couldn't get link information from 
>>> http://localhost:8181/restconf/operational/network-topology:network-topology
>>>  
>>> "success" means could get link information from 
>>> http://localhost:8181/restconf/operational/network-topology:network-topology
>>>  
>>> 
>>> Looking forwarding to any reply. Thank you!
>>> 
>>> Best regards,
>>> Mingming
>>>  
>>> 
>>> 
>>>  
>>> 
>>> 
>>>  
>>> ___
>>> 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] New Openflow meeting time

[Luis Gomez]

Fine with me, I will just join a bit late because of children drop to school.


> On Mar 25, 2018, at 10:23 PM, Prasanna Huddar <prasanna.hud...@ericsson.com> 
> wrote:
> 
> +1
>  
> From: D Arunprakash 
> Sent: Monday, March 26, 2018 10:35 AM
> To: Hema Gopalkrishnan <hema.gopalkrish...@ericsson.com>; Shuva Kar 
> <shuva.jyoti.kar...@gmail.com>; Abhijit Kumbhare <abhijitk...@gmail.com>
> Cc: Anil Vishnoi <vishnoia...@gmail.com>; Jozef Bacigál 
> <jozef.baci...@pantheon.tech>; Luis Gomez Palacios <ece...@gmail.com>; Sunil 
> Kumar G <sunil.g.ku...@ericsson.com>; Bertrand Low <bertrand@hcl.com>; 
> Gobinath . <gobin...@ericsson.com>; Prasanna Huddar 
> <prasanna.hud...@ericsson.com>; openflowplugin-dev@lists.opendaylight.org
> Subject: RE: New Openflow meeting time
>  
> +1, I’m okay with the new timings.
>  
> From: Hema Gopalkrishnan 
> Sent: Monday, March 26, 2018 10:34 AM
> To: Shuva Kar <shuva.jyoti.kar...@gmail.com 
> <mailto:shuva.jyoti.kar...@gmail.com>>; Abhijit Kumbhare 
> <abhijitk...@gmail.com <mailto:abhijitk...@gmail.com>>
> Cc: Anil Vishnoi <vishnoia...@gmail.com <mailto:vishnoia...@gmail.com>>; 
> Jozef Bacigál <jozef.baci...@pantheon.tech 
> <mailto:jozef.baci...@pantheon.tech>>; D Arunprakash 
> <d.arunprak...@ericsson.com <mailto:d.arunprak...@ericsson.com>>; Luis Gomez 
> Palacios <ece...@gmail.com <mailto:ece...@gmail.com>>; Sunil Kumar G 
> <sunil.g.ku...@ericsson.com <mailto:sunil.g.ku...@ericsson.com>>; Bertrand 
> Low <bertrand@hcl.com <mailto:bertrand@hcl.com>>; Gobinath . 
> <gobin...@ericsson.com <mailto:gobin...@ericsson.com>>; Prasanna Huddar 
> <prasanna.hud...@ericsson.com <mailto:prasanna.hud...@ericsson.com>>; 
> openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org>
> Subject: RE: New Openflow meeting time
>  
> Hi Anil,
>   I am fine with the change of time to 8:30 AM PST ,which will be 9 PM IST.
>  
> When the time changes again, it gets a little late here 10 to 11 PM IST. We 
> can re consider the meeting time then.
>  
> Regards
> Hema
>  
> From: Shuva Kar [mailto:shuva.jyoti.kar...@gmail.com 
> <mailto:shuva.jyoti.kar...@gmail.com>] 
> Sent: 26 March 2018 02:49
> To: Abhijit Kumbhare <abhijitk...@gmail.com <mailto:abhijitk...@gmail.com>>
> Cc: Anil Vishnoi <vishnoia...@gmail.com <mailto:vishnoia...@gmail.com>>; 
> Jozef Bacigál <jozef.baci...@pantheon.tech 
> <mailto:jozef.baci...@pantheon.tech>>; D Arunprakash 
> <d.arunprak...@ericsson.com <mailto:d.arunprak...@ericsson.com>>; Luis Gomez 
> Palacios <ece...@gmail.com <mailto:ece...@gmail.com>>; Sunil Kumar G 
> <sunil.g.ku...@ericsson.com <mailto:sunil.g.ku...@ericsson.com>>; Bertrand 
> Low <bertrand@hcl.com <mailto:bertrand@hcl.com>>; Gobinath . 
> <gobin...@ericsson.com <mailto:gobin...@ericsson.com>>; Prasanna Huddar 
> <prasanna.hud...@ericsson.com <mailto:prasanna.hud...@ericsson.com>>; Hema 
> Gopalkrishnan <hema.gopalkrish...@ericsson.com 
> <mailto:hema.gopalkrish...@ericsson.com>>; 
> openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org>
> Subject: Re: New Openflow meeting time
>  
> Am good with the time change to 0830 AM PST
> 
> On Mon 26 Mar, 2018, 02:39 Abhijit Kumbhare, <abhijitk...@gmail.com 
> <mailto:abhijitk...@gmail.com>> wrote:
> Fine with me.
>  
> On Sun, Mar 25, 2018 at 2:07 PM, Anil Vishnoi <vishnoia...@gmail.com 
> <mailto:vishnoia...@gmail.com>> wrote:
> Hi All,
> 
> As discuss in the last meeting, because of the DST change, present meeting 
> time is not convenient for many committers. I am planning to move it to our 
> old meeting time 8:30 AM PST. Please let me know if this time slot works for 
> you or if you have any other time-slot suggestion. If you want me to start 
> doodle-poll on few time slot that covers APAC, Europe and US region, please 
> let me know.
> 
> iPhone.iTypos.iApologize

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

Re: [openflowplugin-dev] Test regression in carbon/nitrogen

[Luis Gomez]

FYI this seems is related to : 
https://jira.opendaylight.org/browse/YANGTOOLS-870 
<https://jira.opendaylight.org/browse/YANGTOOLS-870>

Things should get back to normal after the revert completes.

BR/Luis

> On Mar 23, 2018, at 5:29 PM, Luis Gomez <ece...@gmail.com> wrote:
> 
> Hi yangtools devs,
> 
> This POST request to add groups to a switch worked pretty well a few weeks 
> back:
> 
> POST 
> http://127.0.0.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/
> {
>  "group": [
>{
>  "group-id": 1000,
>  "buckets": {
>"bucket": [
>  {
>"bucket-id": 1,
>"weight": 1,
>"action": [
>  {
>"order": 1,
>"output-action": {
>  "output-node-connector": "1"
>}
>  }
>]
>  }
>]
>  },
>  "group-name": "Select-1",
>  "group-type": "group-select"
>}
>]
> }
> 
> Now I get this:
> 
> {
>"errors": {
>"error": [
>{
>"error-type": "application",
>"error-tag": "operation-failed",
>"error-message": "Data did not pass validation.",
>"error-info": 
> "org.opendaylight.yangtools.yang.data.api.schema.tree.ModifiedNodeDoesNotExistException:
>  Node 
> /(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:1}]/(urn:opendaylight:flow:inventory?revision=2013-08-19)group
>  does not exist. Cannot apply modification to its children.\n\tat 
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkTouchApplicable(AbstractNodeContainerModificationStrategy.java:281)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:125)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkMergeApplicable(AbstractNodeContainerModificationStrategy.java:313)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:131)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkMergeApplicable(AbstractNodeContainerModificationStrategy.java:313)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:131)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkMergeApplicable(AbstractNodeContainerModificationStrategy.java:313)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:131)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.StructuralContainerModificationStrategy.checkApplicable(StructuralContainerModificationStrategy.java:99)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkTouchApplicable(AbstractNodeContainerModificationStrategy.java:288)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:125)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.RootModificationApplyOperation.checkApplicable(RootModificationApplyOperation.java:72)\n\tat
>  
> org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractDataTreeTip.validate(AbstractDataTreeTi

[openflowplugin-dev] Test regression in carbon/nitrogen

[Luis Gomez]

Hi yangtools devs,

This POST request to add groups to a switch worked pretty well a few weeks back:

POST 
http://127.0.0.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/
{
  "group": [
{
  "group-id": 1000,
  "buckets": {
"bucket": [
  {
"bucket-id": 1,
"weight": 1,
"action": [
  {
"order": 1,
"output-action": {
  "output-node-connector": "1"
}
  }
]
  }
]
  },
  "group-name": "Select-1",
  "group-type": "group-select"
}
]
}

Now I get this:

{
"errors": {
"error": [
{
"error-type": "application",
"error-tag": "operation-failed",
"error-message": "Data did not pass validation.",
"error-info": 
"org.opendaylight.yangtools.yang.data.api.schema.tree.ModifiedNodeDoesNotExistException:
 Node 
/(urn:opendaylight:inventory?revision=2013-08-19)nodes/node/node[{(urn:opendaylight:inventory?revision=2013-08-19)id=openflow:1}]/(urn:opendaylight:flow:inventory?revision=2013-08-19)group
 does not exist. Cannot apply modification to its children.\n\tat 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkTouchApplicable(AbstractNodeContainerModificationStrategy.java:281)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:125)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkMergeApplicable(Abst
 ractNodeContainerModificationStrategy.java:313)\n\tat 
org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:131)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkMergeApplicable(AbstractNodeContainerModificationStrategy.java:313)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:131)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkMergeApplicable(AbstractNod
 eContainerModificationStrategy.java:313)\n\tat 
org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:131)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.StructuralContainerModificationStrategy.checkApplicable(StructuralContainerModificationStrategy.java:99)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkChildPreconditions(AbstractNodeContainerModificationStrategy.java:305)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractNodeContainerModificationStrategy.checkTouchApplicable(AbstractNodeContainerModificationStrategy.java:288)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.SchemaAwareApplyOperation.checkApplicable(SchemaAwareApplyOperation.java:125)\n\tat
 
org.opendaylight.yangtools.yang.data.impl.schema.tree.RootModificationApplyOperation.checkApplicable(RootModificationApplyOperation.java:72)\n\tat
 o
 
rg.opendaylight.yangtools.yang.data.impl.schema.tree.AbstractDataTreeTip.validate(AbstractDataTreeTip.java:35)\n\tat
 
org.opendaylight.controller.cluster.datastore.ShardDataTree.lambda$processNextPendingTransaction$0(ShardDataTree.java:723)\n\tat
 
org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextPending(ShardDataTree.java:769)\n\tat
 
org.opendaylight.controller.cluster.datastore.ShardDataTree.processNextPendingTransaction(ShardDataTree.java:716)\n\tat
 
org.opendaylight.controller.cluster.datastore.ShardDataTree.startCanCommit(ShardDataTree.java:799)\n\tat
 
org.opendaylight.controller.cluster.datastore.SimpleShardDataTreeCohort.canCommit(SimpleShardDataTreeCohort.java:90)\n\tat
 
org.opendaylight.controller.cluster.datastore.CohortEntry.canCommit(CohortEntry.java:97)\n\tat
 
org.opendaylight.controller.cluster.datastore.ShardCommitCoordinator.handleCanCommit(ShardCommitCoordinator.java:236)\n\tat
 org.opendaylight.controller.cluster.datastore.ShardCommitCoordinato
 

[openflowplugin-dev] OpenFlow group stats leak

[Luis Gomez]

Hi all,

As commented in this bug:

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


ofplugin has a nasty group stats leak fixed in Carbon:

https://git.opendaylight.org/gerrit/#/c/63896/36/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/registry/group/DeviceGroupRegistryImpl.java
 


But NOT in nitrogen or oxygen.

I opened this ticket to track this as I think it is important to fix this in 
the other 2 branches:

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


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

Re: [openflowplugin-dev] Carbon SR3 Blocker - please provide ETA

[Luis Gomez]

Just to clarify the issue described in OPNFLWPLUG-975 
<https://jira.opendaylight.org/browse/OPNFLWPLUG-975> happens with default 
openflowplugin settings (i.e. stats enabled).

> On Feb 10, 2018, at 10:27 AM, Sunil Kumar G <sunil.g.ku...@ericsson.com> 
> wrote:
> 
> Short summary on the analysis :
> From the statistic collection perspective, this should still be fine, if 
> statistic collection is disabled, this issue will pop-up.
>  
> Raised a patch for this : https://git.opendaylight.org/gerrit/#/c/68130/ 
> <https://git.opendaylight.org/gerrit/#/c/68130/>
>  
> Regards,
> SUnil
>  
>  
> From: Anil Vishnoi [mailto:vishnoia...@gmail.com] 
> Sent: Saturday, February 10, 2018 1:21 AM
> To: Kit Lou <klou.exter...@gmail.com>; Sunil Kumar G 
> <sunil.g.ku...@ericsson.com>; D Arunprakash <d.arunprak...@ericsson.com>
> Cc: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>; Luis 
> Gomez <ece...@gmail.com>
> Subject: Re: Carbon SR3 Blocker - please provide ETA
>  
> Sunil/Arun,
>  
> Can you please look at this issue. Looks like this regression got sneaked in 
> through the below patch that sunil pushed.
>  
> Thanks
> Anil
>  
> On Fri, Feb 9, 2018 at 6:22 AM, Kit Lou <klou.exter...@gmail.com 
> <mailto:klou.exter...@gmail.com>> wrote:
> Hi Anil & openflowplugin Team,
>  
> Please investigate the blocker issue below and provide ETA.  Thanks!
>  
> Best Regards,
> Kit Lou
>  
> On Thu, Feb 8, 2018 at 2:34 PM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> FYI, this patch:
>  
> https://git.opendaylight.org/gerrit/#/c/66304/ 
> <https://git.opendaylight.org/gerrit/#/c/66304/>
>  
> Introduced regression in Carbon:
>  
> https://jira.opendaylight.org/browse/OPNFLWPLUG-975 
> <https://jira.opendaylight.org/browse/OPNFLWPLUG-975>
>  
> This is currently blocking Carbon SR3 so I would suggest to fix this asap.
>  
> Also going forward I recommend OFP committers to run 
> "test-openflowplugin-core" before merging a patch as this regression is 
> caught by our CSIT.
>  
> BR/Luis
>  
> 
> 
>  
> -- 
> Thanks
> Anil

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

[openflowplugin-dev] Regression in Carbon

[Luis Gomez]

FYI, this patch:

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


Introduced regression in Carbon:

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


This is currently blocking Carbon SR3 so I would suggest to fix this asap.

Also going forward I recommend OFP committers to run "test-openflowplugin-core" 
before merging a patch as this regression is caught by our CSIT.

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

Re: [openflowplugin-dev] [OpenDaylight Discuss] Multiple Controller implementation

[Luis Gomez]

> On Feb 7, 2018, at 5:11 PM, Mohamed Abdel Metaal <m.alaa...@hotmail.com> 
> wrote:
> 
> Luis,
>  
> This could not be possible as all controllers in this case will connect to 
> the same openflow ports, RESTCONF, Jolokia ports 8081 and 8080 along with 
> other ports too, so the other 2 controllers will address ports which is 
> already being addressed by the first controller. It would only be possible to 
> work if these ports are changed in each of the other controllers so they 
> don’t collide using the same ports, eg. Openflow ports 6633 / 6653. Just to 
> clarify, as I have forgot, I am implementing this using my Ubuntu machine 
> without the use of virtual machines. That’s another question, could this be 
> implemented using only my local machine without virtual machines and tweaking 
> the ports in each OpenDaylight folder (for each controller)?

I do not think you can bring more than one controller instance in same machine 
unless you use VMs or docker. on both options you do not need to modify 
controller ports.

>  
> Jamo,
>  
> I am currently implementing the controllers in one machine so they have the 
> same address to address the controllers (which is the loopback address in my 
> case). So the controllers in my mininet script have the same ip address but 
> different openflow ports 6653, 7753 and 8853. Again, probably the same 
> question arises, is multiple controllers only possible to implement using 
> different virtual machines per controller?
>  
> Thanks 
>  
> P.S. I have implemented the same implementation before using Floodlight and 
> there was a certain number of ports, including openflow ports, that needs to 
> be changed. All using my local machine without the need for virtual machines.
> If this is possible then it could be also a great idea to benchmark 
> OpenDaylight with other SDN controllers for behavior using a physically 
> distributed control plane.
>  
>  
> From: Jamo Luhrsen <mailto:jluhr...@gmail.com>
> Sent: Thursday, February 8, 2018 1:53
> To: Luis Gomez <mailto:ece...@gmail.com>; Mohamed Abdel Metaal 
> <mailto:m.alaa...@hotmail.com>
> Cc: disc...@lists.opendaylight.org <mailto:disc...@lists.opendaylight.org>; 
> openflowplugin-dev <mailto:openflowplugin-dev@lists.opendaylight.org>
> Subject: Re: [OpenDaylight Discuss] Multiple Controller implementation
>  
> 
> 
> On 2/7/18 4:24 PM, Luis Gomez wrote:
> > 
> >> On Feb 7, 2018, at 4:09 PM, Mohamed Abdel Metaal <m.alaa...@hotmail.com 
> >> <mailto:m.alaa...@hotmail.com><mailto:m.alaa...@hotmail.com 
> >> <mailto:m.alaa...@hotmail.com>>> wrote:
> >>
> >> Hello Jamo,
> >>
> >> Yes exactly, I have one instance of mininet running that should be 
> >> connected to 3 opendaylight controllers. In my
> >> mininet python script i have defined that controllers should connect on 
> >> 6653, 7753 and 8853 openflow ports. This
> >> should be somehow configured also in my opendaylight controllers for it to 
> >> connect. I have tried changing port numbers
> >> in default(and legacy)-openflow-connection-config.xml for the 3 different 
> >> opendaylight controllers and ports 8081/8080
> >> for jetty.xml so they don’t collide but still I get the errors and the 2 
> >> other controllers cannot connect to my
> >> mininet instance.
> 
> Luis,
> 
> is there a config we can tweak to tell OFP which port to listen on?
> 
> Mohamed
> 
> can you tweak your mininet python script to use the actual ip addresses of 
> your
> controllers? seems that those would be different. In that case, why can't they
> all be listening on 6633?
> 
> Thanks,
> JamO
> 
> 
> >> As a brief example just to make sure that my idea is clear: i run a 
> >> mininet instance of 6 switches where each
> >> controller should only see/monitor/connect to 2 of the switches.
> > 
> > I am not sure I full follow here: is this as simple as connect 2 switches 
> > to a first controller, the next 2 switches to
> > a second controller and finally the last 2 switches to a third controller? 
> > if so there is nothing to do in controller,
> > juts need to set mininet or OVS to do this, right?
> > 
> >>
> >> Thank you for your response.
> >>
> >> 
> >> *From:* Jamo Luhrsen <jluhr...@gmail.com <mailto:jluhr...@gmail.com> 
> >> <mailto:jluhr...@gmail.com <mailto:jluhr...@gmail.com>>>
> >> *Sent:* Thursday, 

Re: [openflowplugin-dev] [integration-dev] [Puppet] Carbon installation shows "version 4 not found" error

[Luis Gomez]

I wonder if this is the same or similar to this recent bug: 
https://jira.opendaylight.org/browse/OPNFLWPLUG-974 

> On Jan 18, 2018, at 11:08 PM, Ignacio Dominguez Martinez-Casanueva 
>  wrote:
> 
> Hi Jamo,
> 
> Yes, that's what I meant. ODL also complains about more actions such as 
> NxActionConntrackNodesNodeTableFlowApplyActionsCase or 
> NxActionResubmitNodesNodeGroupBucketsBucketActionsCase.
> 
> For my OpenStack compute nodes I'm running 2.6.1 version.
> 
> $ ovs-vsctl --version
> 
> ovs-vsctl (Open vSwitch) 2.6.1
> DB Schema 7.14.0
> Looking at the output of ovs-vsctl show in the compute node, I can see OVS  
> and the internal bridge are connected to the controller. However, on ODL 
> side, apart from this WARN logs, it seems something is broken (e.g. node does 
> not appear in DLUX).
> 
> Thanks a lot for your help,
> 
> Best regards,
> 
> Ignacio.
> 
> On 18.01.2018 21:33, Jamo Luhrsen wrote:
>> Ignacio,
>> 
>> I missed the karaf.log warning about karaf 4. Maybe you meant this:
>> 
>> NxActionResubmitNodesNodeTableFlowApplyActionsCase for version 4 not 
>> found
>> 
>> That seems like some kind of openflowplugin problem (CC'd that dev list).
>> 
>> what version OVS are you using?
>> 
>> JamO
>> 
>> On 01/18/2018 01:27 AM, Ignacio Dominguez Martinez-Casanueva wrote:
>>> Hello everyone,
>>> 
>>> I'm using OpenDaylight's Puppet module to install latest Carbon version 
>>> opendaylight-6.2.0-1.el7
>>>  
>>>  on CentOS 7. My hiera 
>>> configuration is pretty simple:
>>> 
>>> /opendaylight::rpm_repo: 'opendaylight-6-release' # Carbon latest//
>>> //opendaylight::extra_features://
>>> //  - 'odl-netvirt-openstack'//
>>> //  - 'odl-dlux-core'//
>>> //  - 'odl-mdsal-apidocs'//
>>> //  - 'odl-netvirt-ui'//
>>> //  - 'odl-dluxapps-applications'/
>>> 
>>> For the puppet configuration I'm using stable/carbon branch of repo
>>> https://git.opendaylight.org/gerrit/gitweb?p=integration/packaging/puppet-opendaylight.git
>>>  
>>> 
>>> 
>>> After a fresh installation everything looks ok, however, when I connect an 
>>> OVS switch to the ODL controller I see a lot of
>>> WARN errors in the karaf.log. As you can see, in these logs ODL complains 
>>> about karaf version 4. My understanding is that
>>> Carbon release uses karaf 3, how is this possible? Should I use a different 
>>> branch of the Puppet code?
>>> 
>>> Please, let me attach to this email the karaf.log when a new OVS instance 
>>> connects to the controller.
>>> 
>>> Thank you very much for your attention,
>>> 
>>> 
>>> Best regards,
>>> 
>>> Ignacio.
>>> 
>>> 
>>> 
>>> ___
>>> integration-dev mailing list
>>> integration-...@lists.opendaylight.org 
>>> 
>>> https://lists.opendaylight.org/mailman/listinfo/integration-dev 
>>> 
>>> 
> 
> ___
> integration-dev mailing list
> 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] [Opendaylight-users] Same NodeId attached to two different hardware devices

[Luis Gomez]

Thanks Charif,

So this is clearly a switch problem that cannot be workaround in controller. I 
would suggest to contact Brocade support (or whoever is supporting these 
switches nowadays) and ask for a fix to get different Datapath IDs, as 
otherwise you will not be able to connect both switches to same controller.

BR/Luis


> On Jan 23, 2018, at 1:37 PM, Mahmoudi, Charif (IntlAssoc) 
> <charif.mahmo...@nist.gov> wrote:
> 
> Thanks for your help!
>  
> The Datapath ID sent to the switches is exactly the same. Below the OF as 
> captured by wireshark on the ODL’s host.
>  
> Charif
>  
> [Switch 1]
> BrocadeC_de:d2:01 (60:9c:9f:de:d2:01)
>  
> OpenFlow 1.3
> Version: 1.3 (0x04)
> Type: OFPT_FEATURES_REPLY (6)
> Length: 32
> Transaction ID: 22
> datapath_id: 0xde9f9c60
> n_buffers: 0
> n_tables: 1
> auxiliary_id: 0
> Pad: 0
> capabilities: 0x004f
> Reserved: 0x
>  
> [Switch 2]
> BrocadeC_de:d0:01 (60:9c:9f:de:d0:01)
>  
> OpenFlow 1.3
> Version: 1.3 (0x04)
> Type: OFPT_FEATURES_REPLY (6)
> Length: 32
> Transaction ID: 22
> datapath_id: 0xde9f9c60
> n_buffers: 0
> n_tables: 1
> auxiliary_id: 0
> Pad: 0
> capabilities: 0x004f
>Reserved: 0x
>  
>  
> From: Luis Gomez [mailto:ece...@gmail.com] 
> Sent: Tuesday, January 23, 2018 1:03 PM
> To: Mahmoudi, Charif (IntlAssoc) <charif.mahmo...@nist.gov>; 
> openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
> Cc: opendaylight-us...@lists.opendaylight.org; El Mimouni, Omar Ilias 
> (IntlAssoc) <omarilias.elmimo...@nist.gov>
> Subject: Re: [Opendaylight-users] Same NodeId attached to two different 
> hardware devices
>  
> Hi Charif (cc-ing ofp project),
>  
> Would it be possible to capture the OF traffic between controller and 
> switches and tell which datapath ID is being sent in the features reply 
> message by the 2 switches? this way we can determine if the problem is in the 
> controller or the switches.
>  
> BR/Luis 
>  
> On Jan 23, 2018, at 8:10 AM, Mahmoudi, Charif (IntlAssoc) 
> <charif.mahmo...@nist.gov <mailto:charif.mahmo...@nist.gov>> wrote:
>  
> Hello,
>  
> We are using ODL ( odl-openflowplugin-southbound  0.5.1 ) with two Brocade 
> SLX switches. The witches have very similar MAC addresses ( XX:XX:XX:XX:Xa:XX 
> and XX:XX:XX:XX:Xb:XX ). When we connect the switches to ODL, they are both 
> receiving the same NodeId. 
>  
> Any idea how to resolve that ?
> Thanks for your help.
> Charif  
> ___
> opendaylight-users mailing list
> opendaylight-us...@lists.opendaylight.org 
> <mailto:opendaylight-us...@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/opendaylight-users 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.opendaylight.org%2Fmailman%2Flistinfo%2Fopendaylight-users=02%7C01%7Ccharif.mahmoudi%40nist.gov%7Cef276f7ef90348722bbe08d5628b7b3d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636523273565065245=Egdli5o8%2FZlQTORCUZK39yoroOjLJf2wsCpxfeej51Q%3D=0>
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [Opendaylight-users] Same NodeId attached to two different hardware devices

[Luis Gomez]

Hi Charif (cc-ing ofp project),

Would it be possible to capture the OF traffic between controller and switches 
and tell which datapath ID is being sent in the features reply message by the 2 
switches? this way we can determine if the problem is in the controller or the 
switches.

BR/Luis 

> On Jan 23, 2018, at 8:10 AM, Mahmoudi, Charif (IntlAssoc) 
>  wrote:
> 
> Hello,
>  
> We are using ODL ( odl-openflowplugin-southbound  0.5.1 ) with two Brocade 
> SLX switches. The witches have very similar MAC addresses ( XX:XX:XX:XX:Xa:XX 
> and XX:XX:XX:XX:Xb:XX ). When we connect the switches to ODL, they are both 
> receiving the same NodeId. 
>  
> Any idea how to resolve that ?
> Thanks for your help.
> Charif  
> ___
> opendaylight-users mailing list
> opendaylight-us...@lists.opendaylight.org 
> 
> https://lists.opendaylight.org/mailman/listinfo/opendaylight-users 
> 
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] OFP blocker

[Luis Gomez]

And the issue has been fixed in controller project :)

> On Jan 22, 2018, at 12:28 PM, Luis Gomez <ece...@gmail.com> wrote:
> 
> FYI, this is so far the only OFP related issue reported after the upstream 
> version bump.
> 
> 
>> Begin forwarded message:
>> 
>> From: Brady Johnson <bjohn...@inocybe.ca <mailto:bjohn...@inocybe.ca>>
>> Subject: Re: [yangtools-dev] [release] [Odlparent-dev] What is the latest 
>> status of open issues for the bump?
>> Date: January 22, 2018 at 12:00:14 PM PST
>> To: Kit Lou <klou.exter...@gmail.com <mailto:klou.exter...@gmail.com>>
>> Cc: Luis Gomez <ece...@gmail.com <mailto:ece...@gmail.com>>, Michael 
>> Vorburger <vorbur...@redhat.com <mailto:vorbur...@redhat.com>>, 
>> "d...@lists.opendaylight.org <mailto:d...@lists.opendaylight.org>" 
>> <d...@lists.opendaylight.org <mailto:d...@lists.opendaylight.org>>, 
>> yangtools-dev <yangtools-...@lists.opendaylight.org 
>> <mailto:yangtools-...@lists.opendaylight.org>>, "Release 
>> (rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>)" 
>> <rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>>, 
>> odlparent-dev <odlparent-...@lists.opendaylight.org 
>> <mailto:odlparent-...@lists.opendaylight.org>>
>> 
>> Here is the blocker issue for the OpenFlow plugin issue.
>> 
>> https://jira.opendaylight.org/browse/OPNFLWPLUG-973 
>> <https://jira.opendaylight.org/browse/OPNFLWPLUG-973>
>> 
>> Regards,
>> 
>> Brady Johnson
>> bjohn...@inocybe.ca <mailto:bjohn...@inocybe.ca>
>> 
>> 
>>  <https://twitter.com/inocybetech>  <http://www.inocybe.com/>  
>> <https://www.linkedin.com/company/2661537?trk=tyah=clickedVertical%3Acompany%2CclickedEntityId%3A2661537%2Cidx%3A1-1-1%2CtarId%3A1441300264767%2Ctas%3Ainocybe>
>>   <https://www.youtube.com/channel/UC9uUWABdPR0Je9Du_15FCkw>
>> 
> 

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

[openflowplugin-dev] OFP blocker

[Luis Gomez]

FYI, this is so far the only OFP related issue reported after the upstream 
version bump.


> Begin forwarded message:
> 
> From: Brady Johnson <bjohn...@inocybe.ca>
> Subject: Re: [yangtools-dev] [release] [Odlparent-dev] What is the latest 
> status of open issues for the bump?
> Date: January 22, 2018 at 12:00:14 PM PST
> To: Kit Lou <klou.exter...@gmail.com>
> Cc: Luis Gomez <ece...@gmail.com>, Michael Vorburger <vorbur...@redhat.com>, 
> "d...@lists.opendaylight.org" <d...@lists.opendaylight.org>, yangtools-dev 
> <yangtools-...@lists.opendaylight.org>, "Release 
> (rele...@lists.opendaylight.org)" <rele...@lists.opendaylight.org>, 
> odlparent-dev <odlparent-...@lists.opendaylight.org>
> 
> Here is the blocker issue for the OpenFlow plugin issue.
> 
> https://jira.opendaylight.org/browse/OPNFLWPLUG-973 
> <https://jira.opendaylight.org/browse/OPNFLWPLUG-973>
> 
> Regards,
> 
> Brady Johnson
> bjohn...@inocybe.ca <mailto:bjohn...@inocybe.ca>
> 
> 
>  <https://twitter.com/inocybetech>  <http://www.inocybe.com/>  
> <https://www.linkedin.com/company/2661537?trk=tyah=clickedVertical%3Acompany%2CclickedEntityId%3A2661537%2Cidx%3A1-1-1%2CtarId%3A1441300264767%2Ctas%3Ainocybe>
>   <https://www.youtube.com/channel/UC9uUWABdPR0Je9Du_15FCkw>
> 

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

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

[Luis Gomez]

Vishal (cc-ing ovsdb devs),

FYI I still see problems with topology not accessible on latest int/dist 
distribution:

https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-upstream-southbound-all-oxygen/115/

This is also reproducible locally by installing odl-ovsdb-southbound-impl-rest 
and checking topology API is not available:

{
"errors": {
"error": [
{
"error-type": "application",
"error-tag": "data-missing",
"error-message": "Request could not be completed because the 
relevant data model content does not exist "
}
]
}
}


> On Jan 16, 2018, at 7:43 PM, Vishal Thapar <vishal.tha...@ericsson.com> wrote:
> 
> Hi Luis,
>  
> There is already a Jira [4], and patch [5] from Robert in works. OFPlugin 
> could do a similar workaround to one I did for OVSDB while waiting for 
> Robert’s patch to land.
>  
> Regards,
> Vishal.
>  
> [4] https://jira.opendaylight.org/browse/NETCONF-496
> [5] https://git.opendaylight.org/gerrit/67212
>  
> From: openflowplugin-dev-boun...@lists.opendaylight.org 
> [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Luis 
> Gomez
> Sent: 17 January 2018 08:58
> To: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
> Subject: [openflowplugin-dev] Fwd: [opendaylight-dev] [release] odlparent + 
> yangtools bump
>  
> FYI the topology issue described by Vishal below also happens in 
> openflowplugin, so the proposed workarounds should also work here. Should we 
> open a ticket for this?
>  
> BR/Luis
> 
> 
> Begin forwarded message:
>  
> From: Vishal Thapar <vishal.tha...@ericsson.com>
> Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump
> Date: January 16, 2018 at 6:08:46 AM PST
> To: Tom Pantelis <tompante...@gmail.com>
> Cc: Stephen Kitt <sk...@redhat.com>, odl-dev-list 
> <d...@lists.opendaylight.org>, "yangtools-...@lists.opendaylight.org" 
> <yangtools-...@lists.opendaylight.org>, Release 
> <rele...@lists.opendaylight.org>
>  
> Hi Tom,
>  
> Yeah, this is another workaround. In case of OVSDB I know which version I 
> want to use. But it is still not a proper fix. Something like 
> restconf/apidocs can’t know the correct version. If latest is correct one, 
> should probably move older ones to differently named bundles.
>  
> Regards,
> Vishal.
>  
> From: Tom Pantelis [mailto:tompante...@gmail.com] 
> Sent: 16 January 2018 19:13
> To: Vishal Thapar <vishal.tha...@ericsson.com>
> Cc: Robert Varga <n...@hq.sk>; Stephen Kitt <sk...@redhat.com>; odl-dev-list 
> <d...@lists.opendaylight.org>; Release <rele...@lists.opendaylight.org>; 
> yangtools-...@lists.opendaylight.org
> Subject: Re: [release] [opendaylight-dev] odlparent + yangtools bump
>  
>  
>  
> On Tue, Jan 16, 2018 at 1:57 AM, Vishal Thapar <vishal.tha...@ericsson.com> 
> wrote:
> Thanks for the lead Tom.
>  
> I’m not subscribed to yangtools-dev so they may not get this mail.
>  
> I followed it to new yangtools unable to figure out which version to pick 
> when 2 versions of same model are loaded. Network-topology happens to be one 
> of 8 such instances I saw that have two different versions under same yang 
> file and both are loaded [1]. I think this is more of an existing bad design 
> or oversight being exposed by new yangtools, your opinion may wary.
>  
> I was able to workaround part of OVSDB issue by hardcoding the revision when 
> deserializing [2]. I am now able to use OVSDB plugin to configure OVS, but 
> restconf is still failing as well as odl-mdsal-apidocsc gives 500 error. IMO, 
> there are two ways to take care of this:
>  
>   • Publish and modify all test scripts etc. to specify revision in rest 
> calls too [if possible].
>   • Eliminate duplicate models by moving older models to appropriately 
> named folders, something similar to ietf-yang-types [3] only moving older one 
> to use the revision in folder name, to avoid changes to all consumers.
>   • ‘Fix’ in yangtools to pick the newer version.
>  
> Note that I mention yangtools but this could likely be an mdsal or restconf 
> issue too, am not familiar enough with any of these to make a definitive 
> statement on where the ‘bug’ is. Also, without rest allOVSDB/Genius/Netvirt 
> CSIT will be broken, even if rest of bump activity goes through smoothly.
>  
>  
> This sounds familiar - I ran into it in another project and worked around it: 
> https://git.opendaylight.org/gerrit/#/c/66536/2/impl/src/main/java/org/opend

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

[Luis Gomez]

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

BR/Luis

> On Jan 16, 2018, at 7:43 PM, Vishal Thapar <vishal.tha...@ericsson.com> wrote:
> 
> Hi Luis,
>  
> There is already a Jira [4], and patch [5] from Robert in works. OFPlugin 
> could do a similar workaround to one I did for OVSDB while waiting for 
> Robert’s patch to land.
>  
> Regards,
> Vishal.
>  
> [4] https://jira.opendaylight.org/browse/NETCONF-496 
> <https://jira.opendaylight.org/browse/NETCONF-496>
> [5] https://git.opendaylight.org/gerrit/67212 
> <https://git.opendaylight.org/gerrit/67212>
>  
> From: openflowplugin-dev-boun...@lists.opendaylight.org 
> [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Luis 
> Gomez
> Sent: 17 January 2018 08:58
> To: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
> Subject: [openflowplugin-dev] Fwd: [opendaylight-dev] [release] odlparent + 
> yangtools bump
>  
> FYI the topology issue described by Vishal below also happens in 
> openflowplugin, so the proposed workarounds should also work here. Should we 
> open a ticket for this?
>  
> BR/Luis
> 
> 
> Begin forwarded message:
>  
> From: Vishal Thapar <vishal.tha...@ericsson.com 
> <mailto:vishal.tha...@ericsson.com>>
> Subject: Re: [opendaylight-dev] [release] odlparent + yangtools bump
> Date: January 16, 2018 at 6:08:46 AM PST
> To: Tom Pantelis <tompante...@gmail.com <mailto:tompante...@gmail.com>>
> Cc: Stephen Kitt <sk...@redhat.com <mailto:sk...@redhat.com>>, odl-dev-list 
> <d...@lists.opendaylight.org <mailto:d...@lists.opendaylight.org>>, 
> "yangtools-...@lists.opendaylight.org 
> <mailto:yangtools-...@lists.opendaylight.org>" 
> <yangtools-...@lists.opendaylight.org 
> <mailto:yangtools-...@lists.opendaylight.org>>, Release 
> <rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>>
>  
> Hi Tom,
>  
> Yeah, this is another workaround. In case of OVSDB I know which version I 
> want to use. But it is still not a proper fix. Something like 
> restconf/apidocs can’t know the correct version. If latest is correct one, 
> should probably move older ones to differently named bundles.
>  
> Regards,
> Vishal.
>  
> From: Tom Pantelis [mailto:tompante...@gmail.com 
> <mailto:tompante...@gmail.com>] 
> Sent: 16 January 2018 19:13
> To: Vishal Thapar <vishal.tha...@ericsson.com 
> <mailto:vishal.tha...@ericsson.com>>
> Cc: Robert Varga <n...@hq.sk <mailto:n...@hq.sk>>; Stephen Kitt 
> <sk...@redhat.com <mailto:sk...@redhat.com>>; odl-dev-list 
> <d...@lists.opendaylight.org <mailto:d...@lists.opendaylight.org>>; Release 
> <rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>>; 
> yangtools-...@lists.opendaylight.org 
> <mailto:yangtools-...@lists.opendaylight.org>
> Subject: Re: [release] [opendaylight-dev] odlparent + yangtools bump
>  
>  
>  
> On Tue, Jan 16, 2018 at 1:57 AM, Vishal Thapar <vishal.tha...@ericsson.com 
> <mailto:vishal.tha...@ericsson.com>> wrote:
> Thanks for the lead Tom.
>  
> I’m not subscribed to yangtools-dev so they may not get this mail.
>  
> I followed it to new yangtools unable to figure out which version to pick 
> when 2 versions of same model are loaded. Network-topology happens to be one 
> of 8 such instances I saw that have two different versions under same yang 
> file and both are loaded [1]. I think this is more of an existing bad design 
> or oversight being exposed by new yangtools, your opinion may wary.
>  
> I was able to workaround part of OVSDB issue by hardcoding the revision when 
> deserializing [2]. I am now able to use OVSDB plugin to configure OVS, but 
> restconf is still failing as well as odl-mdsal-apidocsc gives 500 error. IMO, 
> there are two ways to take care of this:
>  
> Publish and modify all test scripts etc. to specify revision in rest calls 
> too [if possible].
> Eliminate duplicate models by moving older models to appropriately named 
> folders, something similar to ietf-yang-types [3] only moving older one to 
> use the revision in folder name, to avoid changes to all consumers.
> ‘Fix’ in yangtools to pick the newer version.
>  
> Note that I mention yangtools but this could likely be an mdsal or restconf 
> issue too, am not familiar enough with any of these to make a definitive 
> statement on where the ‘bug’ is. Also, without rest allOVSDB/Genius/Netvirt 
> CSIT will be broken, even if rest of bump activity goes through smoothly.
>  
>  
> This sounds fa

[openflowplugin-dev] Build timeout issues

[Luis Gomez]

cc-ing the release list in case other devs are experiencing similar problems 
with their builds.

> On Dec 15, 2017, at 11:31 AM, Thanh Ha <thanh...@linuxfoundation.org> wrote:
> 
> Alright I talked to Andy and we're gonna bump all the java-builders to the 
> v1-performance-2 machines. This should  (hopefully) make those jobs pass more 
> quickly.
> 
> Regards,
> Thanh
> 
> On Fri, Dec 15, 2017 at 2:18 PM, Thanh Ha <thanh...@linuxfoundation.org 
> <mailto:thanh...@linuxfoundation.org>> wrote:
> Let me think about this a bit. I think the slowness is because in the new 
> cloud we went from 2 CPUs (old) to 1 CPU (new). The new provider provides the 
> following flavors for us:
> 
> v1-performance-1: 1 cpu & 4 gb ram
> v1-performance-2: 2 cpu & 8 gb ram
> v1-performance-4: 4 cpu & 16 gb ram
> v1-performance-8: 8 cpu & 32 gb ram
> 
> So to get the performance back to where we were in the old cloud we should be 
> using performance-2 nodes instead but that means our builders will now 
> default to 8 gb builders which I'm not sure we want to do right now.
> 
> I've asked the cloud provider if we can get a 2 cpu & 4 gb ram flavor and 
> will ask internally if going with the performance-2 right is something we 
> want to take a hit on.
> 
> Regards,
> Thanh
> 
> On Fri, Dec 15, 2017 at 1:41 PM, Tom Pantelis <tompante...@gmail.com 
> <mailto:tompante...@gmail.com>> wrote:
> Sorry I though an individual SFT took an hour but I think Luis is right - 
> it's the overall build time:
> 
> 17:49:31 Running org.opendaylight.odlparent.featuretest.SingleFeatureTest
> 17:50:12 Build timed out (after 60 minutes). Marking the build as failed.
> 
> This is happening in several projects (at least). Thanh - I assume there's a 
> default setting - if so, can you increase it to like 2 hrs? I'm hoping it 
> doesn't need to be set per project.
> 
> On Fri, Dec 15, 2017 at 12:39 PM, Thanh Ha <thanh...@linuxfoundation.org 
> <mailto:thanh...@linuxfoundation.org>> wrote:
> All of our maven-* jobs have a "build-timeout" parameter that let's you 
> override. Just add it to the project.yaml file. Here's an example in releng:
> 
> https://github.com/opendaylight/releng-builder/blob/master/jjb/releng-jobs.yaml#L25
>  
> <https://github.com/opendaylight/releng-builder/blob/master/jjb/releng-jobs.yaml#L25>
> 
> Regards,
> Thanh
> 
> 
> On Fri, Dec 15, 2017 at 12:10 PM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> I suspect the reason is:
> 
> Build timed out (after 60 minutes). Marking the build as failed.
> 
> I believe some projects in ODL take ~1 hour to build and probably more after 
> the cloud migration. Thanh, do you know where to change this timeout?
> 
> BR/Luis
> 
> 
>> On Dec 15, 2017, at 5:49 AM, Tom Pantelis <tompante...@gmail.com 
>> <mailto:tompante...@gmail.com>> wrote:
>> 
>> Hello,
>> 
>> I pushed patches to do the bump and fix build errors:
>> 
>> https://git.opendaylight.org/gerrit/#/c/66493/ 
>> <https://git.opendaylight.org/gerrit/#/c/66493/> - Fix odlparent 3 
>> Checkstyle issues
>> https://git.opendaylight.org/gerrit/#/c/66494/ 
>> <https://git.opendaylight.org/gerrit/#/c/66494/> - Bump to yangtools-2.0.0 
>> and odlparent-3.0.2
>> 
>> The first one should build but got an SFT timeout - don't know why - passes 
>> locally for me. 
>> 
>> Not sure who all the active committers are now but I'll leave it in your 
>> hands now.
>> 
>> Anil - I tried to add you as reviewer but it said it didn't recognize you. 
>> It would seem your account is disabled after the gerrit migration...
>> 
>> Tom
>> ___
>> openflowplugin-dev mailing list
>> openflowplugin-dev@lists.opendaylight.org 
>> <mailto:openflowplugin-dev@lists.opendaylight.org>
>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
>> <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] odlparent 3/yangtools 2 version bump

[Luis Gomez]

I suspect the reason is:

Build timed out (after 60 minutes). Marking the build as failed.

I believe some projects in ODL take ~1 hour to build and probably more after 
the cloud migration. Thanh, do you know where to change this timeout?

BR/Luis


> On Dec 15, 2017, at 5:49 AM, Tom Pantelis  wrote:
> 
> Hello,
> 
> I pushed patches to do the bump and fix build errors:
> 
> https://git.opendaylight.org/gerrit/#/c/66493/ 
>  - Fix odlparent 3 Checkstyle 
> issues
> https://git.opendaylight.org/gerrit/#/c/66494/ 
>  - Bump to yangtools-2.0.0 
> and odlparent-3.0.2
> 
> The first one should build but got an SFT timeout - don't know why - passes 
> locally for me. 
> 
> Not sure who all the active committers are now but I'll leave it in your 
> hands now.
> 
> Anil - I tried to add you as reviewer but it said it didn't recognize you. It 
> would seem your account is disabled after the gerrit migration...
> 
> Tom
> ___
> 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] Jira issues clean up is done

[Luis Gomez]

No severity lists first but then I see: critical > minor > normal > major

> On Dec 12, 2017, at 10:26 AM, Jamo Luhrsen <jluhr...@gmail.com> wrote:
> 
> Luis,
> 
> is it because not every bug has a severity assigned to it? I noticed the 
> netvirt
> project wasn't listing issues like I expected when I sorted by priority. I 
> found
> it was because most of the netvirt issues had no priority at all, and all the
> ones that did were ending up at the end of the list.
> 
> Is that what's happening to you?
> 
> JamO
> 
> On 12/12/2017 10:08 AM, Luis Gomez wrote:
>> When I try to sort the bugs by severity it does not give the right order, is 
>> this only happening to me?
>> 
>> 
>>> On Dec 12, 2017, at 1:45 AM, Anil Vishnoi <vishnoia...@gmail.com 
>>> <mailto:vishnoia...@gmail.com> <mailto:vishnoia...@gmail.com 
>>> <mailto:vishnoia...@gmail.com>>> wrote:
>>> 
>>> Hi Committers/Contributors,
>>> 
>>> OpenFlow project jira dashboard is now cleaned up and all the 
>>> resolved/inactive bugs are now closed. Following are the URLs
>>> for the category of issues open 
>>> 
>>> Bugs : 
>>> 
>>> https://jira.opendaylight.org/browse/OPNFLWPLUG-962?jql=project%20%3D%20OPNFLWPLUG%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20%22In%20Review%22%2C%20Confirmed)%20ORDER%20BY%20created%20DESC
>>> 
>>> Improvements : 
>>> https://jira.opendaylight.org/browse/OPNFLWPLUG-898?jql=project%20%3D%20OPNFLWPLUG%20AND%20issuetype%20%3D%20Improvement%20AND%20status%20in%20(Open%2C%20Confirmed)%20ORDER%20BY%20created%20DESC
>>> 
>>> New Features:
>>> https://jira.opendaylight.org/browse/OPNFLWPLUG-951?jql=project%20%3D%20OPNFLWPLUG%20AND%20issuetype%20%3D%20%22New%20Feature%22%20AND%20status%20in%20(Open%2C%20Confirmed)%20ORDER%20BY%20created%20DESC
>>> 
>>> If you want to contribute to the project, please pick up the issues from 
>>> any of these three list and assign it to yourself.
>>> 
>>> If you are already working on an issue and have patch under review, please 
>>> update the bug with the details and if your
>>> patch is already merged, please close the jira issue.
>>> 
>>> Please feel free to reach out to me if you need further details.
>>> 
>>> -- 
>>> Thanks
>>> Anil
>>> ___
>>> openflowplugin-dev mailing list
>>> openflowplugin-dev@lists.opendaylight.org 
>>> <mailto:openflowplugin-dev@lists.opendaylight.org> 
>>> <mailto:openflowplugin-dev@lists.opendaylight.org 
>>> <mailto:openflowplugin-dev@lists.opendaylight.org>>
>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
>>> <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 
>> <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] Possible MDSAL issue -- how to debug?

[Luis Gomez]

Only issue I can think here is if both actions you are trying have the same 
"order" parameter. And since order is the list key, you may be hitting this 
bug: https://jira.opendaylight.org/browse/YANGTOOLS-834 


grouping action-list {
list action {
key "order";
uses ordered;
uses action;
}
}


> On Dec 8, 2017, at 6:43 PM, M. Ranganathan  wrote:
> 
> Hi Anil,
> 
> The push vlan is working fine. It does not work when I have a push and a goto 
> instruction.
> 
> Either the push OR the goto shows up. I cannot have BOTH push and goto in the 
> same flow. 
> 
> I am working via the java API. I am working with the Carbon-42 openflow 
> plugin. 
> 
> Please see attached Java file.
> 
> I had planned to reproduce the issue using a stand alone test script using 
> the XML API.
> 
> Let me know if I should do that.
> 
> Thank you for your help.
> 
> Regards,
> 
> Ranga
> 
> 
> 
> On Fri, Dec 8, 2017 at 8:35 PM, Anil Vishnoi  > wrote:
> can you please paste me the flow that you are writing to the datastore? 
> Because i tried to push the PUSH_VLAN flow that you mentioned above and i was 
> able to push the flow successfully and i see the same data in the config data 
> store when i fetched it back.
> 
> On Wed, Dec 6, 2017 at 8:27 AM, M. Ranganathan  > wrote:
> 
> 
> I logged everything that I send to the transaction. When I print out the flow 
> (which follows a yang model), I can see all the elements in there (see my 
> previous mail in this thread). It is possible that the openflow southbound 
> plugin which stuffs the datstore (?)  does not like something and is silently 
> stripping out data. Once the transaction is submitted and commit succeeds, 
> the app should be able to release references to the data. Indeed I am making 
> the whole commit synchronous to avoid shooting myself in the foot.
> 
> I will engage with the openflow plugin developers to see how I can track this 
> down. I hope somebody will respond from the openflowplugin-dev list to let me 
> know what debug I should turn on so I can produce some more diagnostics. 
> 
> So in summary, I am able to reproduce the following action in a flow via the 
> JAVA API. 
> 
> https://wiki.opendaylight.org/view/Editing_OpenDaylight_OpenFlow_Plugin:End_to_End_Flows:Example_Flows#Push_VLAN
>  
> 
> 
> I can mimic what the REST api does by direct JAVA calls and the flow does 
> appear but what I want is to ALSO have a goto. This is my issue. If the GOTO 
> is added to the flow, the VLAN push action is stripped off.
> 
> Thanks for your tips and sorry for the number of mails on this.
> 
> 
> 
> 
> On Wed, Dec 6, 2017 at 11:16 AM, Tom Pantelis  > wrote:
> 
> 
> On Wed, Dec 6, 2017 at 10:46 AM, M. Ranganathan  > wrote:
> Hi Ryan, 
> 
> Thanks for forwarding but what is puzzling me is why the flow does not appear 
> as it should in the Config Datastore. If the YANG model matches should it not 
> appear in the config datastore? 
> 
> I could see it as an openflow problem if I saw an exception why trying to 
> instantiate the flow.
> 
> I was suspecting MDSAL for this reason. Perhaps I am mistaken.
> 
> The MDSAL commits exactly what clients tell it to do, ie it doesn't randomly 
> omit or strip out data. I'm not that familiar with OFP and I'm not really 
> clear on exactly what you're doing but if something is missing in the data 
> then I suspect either it isn't getting written or it was deleted or 
> overwritten somewhere along the line in the app code.
>  
> 
> Thanks.
> 
> Ranga
> 
> 
> 
> 
> -- 
> M. Ranganathan
> 
> “If debugging is the process of removing software bugs, then programming must 
> be the process of putting them in.” – Edsger Dijkstra
> 
> 
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org 
> 
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> 
> 
> 
> 
> 
> -- 
> Thanks
> Anil
> 
> 
> 
> -- 
> M. Ranganathan
> 
> “If debugging is the process of removing software bugs, then programming must 
> be the process of putting them in.” – Edsger Dijkstra
> 
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org 
> 
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> 

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

[Luis Gomez]

Thanks Abhijit and congrats Anil!

> On Dec 9, 2017, at 4:15 PM, Abhijit Kumbhare  wrote:
> 
> 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 
>> 
> 
> 
> ___
> 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] [controller-users] br-int default flows

[Luis Gomez]

I think the easier would be to do new installation skipping l2switch 
application. That would get rid of the the undesired flows.

> On Nov 16, 2017, at 2:32 AM, Igor Levchuk  wrote:
> 
> Hi,
> 
> You are right. In this case its l2switch app I think.
> But what do I do wrong here ?
> 
> I have unpacked Nitrogen, started karaf and installed apropriate plugins ( 
> like odl-l2switch-all) but I can't not find file arp-handler-config.yang 
> which is mentioned into documentation you sent to perform changes.
> 
> Thanks!
> 
> 11/15/17 23:40, Jamo Luhrsen пише:
>> Hard to follow what you are doing here, but maybe you are using the l2switch 
>> app?
>> I know that will put some default flows so it can do things like learn links:
>> http://docs.opendaylight.org/en/latest/user-guide/l2switch-user-guide.html?highlight=default
>>  flows
>> you can add/remove flows via NB and openflowplugin:
>> http://docs.opendaylight.org/en/latest/user-guide/openflow-plugin-project-user-guide.html?highlight=push%20flows#end-to-end-flows
>> Not sure if it helps.
>> JamO
>> On 11/15/2017 10:26 AM, Igor Levchuk wrote:
>>> Hi,
>>> 
>>> Actually, I am not trying to install features. I have already installed 
>>> them. Here is full list:
>>> 
>>> odl-l2switch-addresstracker
>>> odl-aaa-encryption-service
>>> odl-openflowplugin-nsf-model
>>> jdbc
>>> odl-javassist-3
>>> odl-openflowplugin-app-topology
>>> odl-dluxapps-yangutils
>>> odl-openflowjava-protocol
>>> odl-ovsdb-southbound-api
>>> pax-jdbc-spec
>>> pax-jdbc
>>> pax-jdbc-config
>>> odl-mdsal-eos-common
>>> odl-mdsal-broker
>>> odl-mdsal-binding-api
>>> odl-karaf-feat-jdbc
>>> odl-mdsal-binding-base
>>> odl-aaa-shiro
>>> odl-l2switch-all
>>> odl-aaa-cert
>>> odl-akka-clustering-2.4
>>> odl-l2switch-packethandler
>>> odl-config-netty
>>> odl-guava-22
>>> odl-mdsal-common
>>> odl-openflowplugin-app-config-pusher
>>> odl-ovsdb-hwvtepsouthbound-ui
>>> odl-l2switch-switch
>>> odl-mdsal-dom-broker
>>> odl-mdsal-dom-api
>>> odl-akka-system-2.4
>>> odl-mdsal-common
>>> odl-akka-persistence-2.4
>>> odl-openflowplugin-app-reconciliation-framework
>>> odl-dluxapps-yangui
>>> odl-mdsal-binding-runtime
>>> odl-ovsdb-hwvtepsouthbound-api
>>> odl-restconf-noauth
>>> odl-l2switch-arphandler
>>> odl-mdsal-remoterpc-connector
>>> odl-yangtools-yang-data
>>> odl-ovsdb-hwvtepsouthbound
>>> odl-mdsal-clustering-commons
>>> odl-lmax-3
>>> odl-mdsal-broker-local
>>> odl-l2switch-hosttracker
>>> odl-mdsal-models
>>> odl-karaf-feat-jetty
>>> odl-dluxapps-topology
>>> odl-ovsdb-southbound-impl
>>> odl-config-manager
>>> odl-config-api
>>> odl-dluxapps-yangvisualizer
>>> odl-mdsal-eos-dom
>>> odl-dluxapps-applications
>>> odl-openflowplugin-app-forwardingrules-manager
>>> odl-config-startup
>>> odl-ovsdb-hwvtepsouthbound-rest
>>> odl-config-netty-config-api
>>> odl-ovsdb-southbound-impl-ui
>>> odl-l2switch-loopremover
>>> odl-config-persister
>>> odl-openflowplugin-flow-services
>>> odl-mdsal-apidocs
>>> odl-mdsal-distributed-datastore
>>> odl-ovsdb-library
>>> odl-dluxapps-yangman
>>> odl-mdsal-binding-dom-adapter
>>> pax-jetty
>>> pax-http-jetty
>>> pax-http
>>> pax-http-whiteboard
>>> pax-war
>>> odl-restconf
>>> odl-yangtools-yang-parser
>>> odl-openflowplugin-southbound
>>> odl-mdsal-singleton-common
>>> odl-dlux-core
>>> odl-dluxapps-nodes
>>> odl-netty-4
>>> odl-mdsal-singleton-dom
>>> odl-yangtools-common
>>> odl-mdsal-dom
>>> southbound-features
>>> odl-ovsdb-southbound-impl-rest
>>> odl-config-core
>>> odl-ovsdb-southbound-test
>>> odl-mdsal-eos-binding
>>> odl-akka-scala-2.11
>>> features-dluxapps
>>> odl-aaa-api
>>> aries-proxy
>>> aries-blueprint
>>> feature
>>> shell
>>> shell-compat
>>> deployer
>>> bundle
>>> config
>>> diagnostic
>>> instance
>>> jaas
>>> log
>>> package
>>> service
>>> system
>>> http
>>> war
>>> kar
>>> ssh
>>> management
>>> wrap
>>> standard
>>> odl-akka-leveldb-0.7
>>> 
>>> 
>>> I am using Nitrogen release.
>>> 
>>> I am simply trying to work with flows and bridge br-int. And I am wondering 
>>> if there is an option to perform changes to the
>>> default list of flows which apllies to the br-int by default.  I just want 
>>> to change them and can't find any information how
>>> to do it.
>>> 
>>> Thanks!
>>> 
>>> 
>>> 11/15/17 18:11, Jamo Luhrsen пише:
 Hi Igor,
 
 I've added openflowplugin-dev and netvirt-dev mailing lists as those are
 probably more appropriate than controller-dev.
 
 Someone there can probably help, but can you also let us know what
 ODL features you are installing?
 
 Thanks,
 JamO
 
 On 11/15/2017 04:49 AM, Igor Levchuk wrote:
> Hello,
> 
> Could someone point me in right direction.
> Trying to figure out how can I change default flows for th br-int form:
> OFPST_FLOW reply (OF1.3) (xid=0x2):
>   cookie=0x2b01, duration=12.664s, table=0, n_packets=0, 
> n_bytes=0, priority=100,dl_type=0x88cc
> actions=CONTROLLER:65535
>   

Re: [openflowplugin-dev] A question regarding VLAN tagging and untagging

[Luis Gomez]

> On Nov 5, 2017, at 5:18 PM, Xingjun Chu <xingjun@huawei.com> wrote:
> 
> hi Luis
> 
> thanks.
> 
> is there a way to define a wild card match for example for any vlan header? 
> doesnt have to be a specific one ? if there is an example code even better. 

yes, just set vlan-id-present=true and skip vlan-id:

"vlan-match": {
"vlan-id": {
"vlan-id-present": true
}
},


> 
> i tried to set a vlan match for example vlan id 100. when it is installed,  
> the match entry in the ovs flow showd a vlan tci match with a vid 100 and a 
> mask 1fff, i have no idea how the mask is set and by who, which doesnt 
> actually match  vlan 100 traffic for some reason.

I think these are OVS specifics, so I would recommend to check OVS 
documentation.

> 
> thanks
> Xingjun
> --
> Xingjun Chu Xingjun Chu
> M:
> E: xingjun@huawei.com
> 2012实验室-渥太华光系统能力中心
> 2012 Laboratories-Ottawa Optical System Competency Centre
> 发件人：Luis Gomez
> 收件人：Xingjun Chu,
> 抄 
> 送：ovsdb-...@lists.opendaylight.org,openflowplugin-dev@lists.opendaylight.org,faas-...@lists.opendaylight.org,
> 时间：2017-11-05 19:44:18
> 主 题：Re: [openflowplugin-dev] A question regarding VLAN tagging and untagging
> 
> Hi Xingjun, AFAIR you have to specify VLAN match when you set or pop vlan, 
> not when you push.
> 
> 
> > On Nov 5, 2017, at 7:13 AM, Xingjun Chu <xingjun@huawei.com> wrote:
> > 
> > BTW,
> > 
> > On top of the previous email, as an example, here is the  flow table with 
> > vlan pop action I dumped using openflow rest api. it is in config, but not 
> > installed.
> > 
> > {
> > "flow-node-inventory:table": [
> > {
> > "id": 80,
> > "flow": [
> > {
> > "id": "DEFAULT_PIPELINE_FLOW_80",
> > "hard-timeout": 0,
> > "idle-timeout": 0,
> > "match": {},
> > "instructions": {
> > "instruction": [
> > {
> > "order": 0,
> > "apply-actions": {
> > "action": [
> > {
> > "order": 0,
> > "pop-vlan-action": {}
> > }
> > ]
> > }
> > },
> > {
> > "order": 1,
> > "go-to-table": {
> > "table_id": 110
> > }
> > }
> > ]
> > },
> > "barrier": true,
> > "priority": 0,
> > "table_id": 80,
> > "flow-name": "DEFAULT_PIPELINE_FLOW_80"
> > }
> > ]
> > }
> > ]
> > }
> > 
> > 
> > thanks
> > Xingjun
> > From: Xingjun Chu
> > Sent: Sunday, November 05, 2017 9:28 AM
> > To: ovsdb-...@lists.opendaylight.org; 
> > openflowplugin-dev@lists.opendaylight.org
> > Cc: faas-...@lists.opendaylight.org
> > Subject: A question regarding VLAN tagging and untagging 
> > 
> > Hi, 
> > 
> > I have a couple of questions regarding the VLAN relevant action.
> > 
> > 1) I have a table in the pipeline which does some L3 forwarding. it has 
> > some entries to match dst ip, then modify dst dl address, dec-ttl, 
> > resubmit. etc...  Those flows get installed without problem.
> > . 
> > Now I try to add a "VLAN strip or pop" into the action list of the flow 
> > above for example as the first action , strip or pop VLAN, then modify dst 
> > dl address, dec-ttl,  resubmit, etc...  I tried both strip or pop action, 
> > but either way the flow didn't get i

Re: [openflowplugin-dev] A question regarding VLAN tagging and untagging

[Luis Gomez]

Hi Xingjun, AFAIR you have to specify VLAN match when you set or pop vlan, not 
when you push.


> On Nov 5, 2017, at 7:13 AM, Xingjun Chu  wrote:
> 
> BTW,
> 
> On top of the previous email, as an example, here is the  flow table with 
> vlan pop action I dumped using openflow rest api. it is in config, but not 
> installed.
> 
> {
> "flow-node-inventory:table": [
> {
> "id": 80,
> "flow": [
> {
> "id": "DEFAULT_PIPELINE_FLOW_80",
> "hard-timeout": 0,
> "idle-timeout": 0,
> "match": {},
> "instructions": {
> "instruction": [
> {
> "order": 0,
> "apply-actions": {
> "action": [
> {
> "order": 0,
> "pop-vlan-action": {}
> }
> ]
> }
> },
> {
> "order": 1,
> "go-to-table": {
> "table_id": 110
> }
> }
> ]
> },
> "barrier": true,
> "priority": 0,
> "table_id": 80,
> "flow-name": "DEFAULT_PIPELINE_FLOW_80"
> }
> ]
> }
> ]
> }
> 
> 
> thanks
> Xingjun
> From: Xingjun Chu
> Sent: Sunday, November 05, 2017 9:28 AM
> To: ovsdb-...@lists.opendaylight.org; 
> openflowplugin-dev@lists.opendaylight.org
> Cc: faas-...@lists.opendaylight.org
> Subject: A question regarding VLAN tagging and untagging 
> 
> Hi, 
> 
> I have a couple of questions regarding the VLAN relevant action.
> 
> 1) I have a table in the pipeline which does some L3 forwarding. it has some 
> entries to match dst ip, then modify dst dl address, dec-ttl, resubmit. 
> etc...  Those flows get installed without problem.
> . 
> Now I try to add a "VLAN strip or pop" into the action list of the flow above 
> for example as the first action , strip or pop VLAN, then modify dst dl 
> address, dec-ttl,  resubmit, etc...  I tried both strip or pop action, but 
> either way the flow didn't get installed. why is that?
> 
> I even tried to just create a separate table with VLAN strip and resubmit as 
> the default entry, it doesn't get installed either.
> 
> 2) also I found more strange thing is that If I need to push and set a VLAN 
> ID in the action, Ihave to have a VLAN match first, otherwise 
> the flow is not get installed.   
> 
> BTW I am doing this NOT using REST API of openflowplugin. but 
> programmatically using Action, Action builder  etc...
> 
> Any pointer is greatly appreciated.
> 
> Thanks & Regards
> Xingjun
> 
> 
> 
>  
> ___
> 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] [integration-dev] SFT failures in distribution-check

[Luis Gomez]

OK, now ofp patches are ready for review:

master:
https://git.opendaylight.org/gerrit/#/c/64783/ 
<https://git.opendaylight.org/gerrit/#/c/64783/>

nitrogen:
https://git.opendaylight.org/gerrit/#/c/64784/ 
<https://git.opendaylight.org/gerrit/#/c/64784/>

The one in master fails in javadocs but I think this is expected given how the 
maven goal works (fetch from nexus vs search in pom files).

BR/luis


> On Oct 26, 2017, at 9:37 PM, Luis Gomez <ece...@gmail.com> wrote:
> 
> FYI below patches have to wait for couple of reverts:
> 
> https://git.opendaylight.org/gerrit/#/c/64789/ 
> <https://git.opendaylight.org/gerrit/#/c/64789/>
> https://git.opendaylight.org/gerrit/#/c/64790/ 
> <https://git.opendaylight.org/gerrit/#/c/64790/>
> 
> As I cannot get proper verification with current dest-check situation.
> 
> BR/Luis
> 
> 
>> On Oct 26, 2017, at 6:45 PM, Luis Gomez <ece...@gmail.com 
>> <mailto:ece...@gmail.com>> wrote:
>> 
>> master:
>> https://git.opendaylight.org/gerrit/#/c/64783/ 
>> <https://git.opendaylight.org/gerrit/#/c/64783/>
>> 
>> nitrogen:
>> https://git.opendaylight.org/gerrit/#/c/64784/ 
>> <https://git.opendaylight.org/gerrit/#/c/64784/>
>> 
>> 
>>> On Oct 26, 2017, at 5:18 PM, Luis Gomez <ece...@gmail.com 
>>> <mailto:ece...@gmail.com>> wrote:
>>> 
>>> Problem is hard coded feature + bundle version in this patch that is also 
>>> in master branch.
>>> 
>>> https://git.opendaylight.org/gerrit/#/c/64238/ 
>>> <https://git.opendaylight.org/gerrit/#/c/64238/>
>>> 
>>> I will file a patch today for this if nobody does before.
>>> 
>>> PS- This should be one of these corner cases our distribution-check cannot 
>>> detect before the patch is actually merged.
>>> 
>>> BR/Luis
>>> 
>>> 
>>> 
>>>> On Oct 26, 2017, at 1:19 PM, Tom Pantelis <tompante...@gmail.com 
>>>> <mailto:tompante...@gmail.com>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> Anybody know what's changed today to cause this failure (it's happening 
>>>> every time so not intermittent) - 
>>>> https://jenkins.opendaylight.org/releng/job/infrautils-distribution-check-oxygen/159/console
>>>>  
>>>> <https://jenkins.opendaylight.org/releng/job/infrautils-distribution-check-oxygen/159/console>
>>>> 
>>>> 19:58:38 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
>>>> 170.206 sec <<< FAILURE! - in 
>>>> org.opendaylight.odlparent.featuretest.SingleFeatureTest
>>>> 19:58:38 
>>>> installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl:
>>>>  
>>>> file:/w/workspace/infrautils-distribution-check-oxygen/distribution/features/singles/odl-integration-compatible-with-1node/target/feature/feature.xml,
>>>>  Feature: odl-integration-compatible-with-1node 0.8.0.SNAPSHOT]  Time 
>>>> elapsed: 168.097 sec  <<< ERROR!
>>>> 19:58:38 org.apache.karaf.features.internal.util.MultiException: Error 
>>>> restarting bundles
>>>> 19:58:38   at 
>>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:865)
>>>> 19:58:38   at 
>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1188)
>>>> 19:58:38   at 
>>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1086)
>>>> 19:58:38   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> 19:58:38   at 
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>> 19:58:38   at 
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> 19:58:38   at java.lang.Thread.run(Thread.java:748)
>>>> 19:58:38   Suppressed: org.osgi.framework.BundleException: Exception in 
>>>> org.opendaylight.netconf.tcp.osgi.NetconfTCPActivator.start() of bundle 
>>>> org.opendaylight.netconf.tcp.
>>>> 19:58:38   at 
>>>> org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792)
>>>> 19:58:38   at 
>>>> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
>>>> 19:58:38   at 
>>>> org.eclipse.osgi.internal.framework

Re: [openflowplugin-dev] [integration-dev] SFT failures in distribution-check

[Luis Gomez]

FYI below patches have to wait for couple of reverts:

https://git.opendaylight.org/gerrit/#/c/64789/ 
<https://git.opendaylight.org/gerrit/#/c/64789/>
https://git.opendaylight.org/gerrit/#/c/64790/ 
<https://git.opendaylight.org/gerrit/#/c/64790/>

As I cannot get proper verification with current dest-check situation.

BR/Luis


> On Oct 26, 2017, at 6:45 PM, Luis Gomez <ece...@gmail.com> wrote:
> 
> master:
> https://git.opendaylight.org/gerrit/#/c/64783/ 
> <https://git.opendaylight.org/gerrit/#/c/64783/>
> 
> nitrogen:
> https://git.opendaylight.org/gerrit/#/c/64784/ 
> <https://git.opendaylight.org/gerrit/#/c/64784/>
> 
> 
>> On Oct 26, 2017, at 5:18 PM, Luis Gomez <ece...@gmail.com 
>> <mailto:ece...@gmail.com>> wrote:
>> 
>> Problem is hard coded feature + bundle version in this patch that is also in 
>> master branch.
>> 
>> https://git.opendaylight.org/gerrit/#/c/64238/ 
>> <https://git.opendaylight.org/gerrit/#/c/64238/>
>> 
>> I will file a patch today for this if nobody does before.
>> 
>> PS- This should be one of these corner cases our distribution-check cannot 
>> detect before the patch is actually merged.
>> 
>> BR/Luis
>> 
>> 
>> 
>>> On Oct 26, 2017, at 1:19 PM, Tom Pantelis <tompante...@gmail.com 
>>> <mailto:tompante...@gmail.com>> wrote:
>>> 
>>> Hello,
>>> 
>>> Anybody know what's changed today to cause this failure (it's happening 
>>> every time so not intermittent) - 
>>> https://jenkins.opendaylight.org/releng/job/infrautils-distribution-check-oxygen/159/console
>>>  
>>> <https://jenkins.opendaylight.org/releng/job/infrautils-distribution-check-oxygen/159/console>
>>> 
>>> 19:58:38 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
>>> 170.206 sec <<< FAILURE! - in 
>>> org.opendaylight.odlparent.featuretest.SingleFeatureTest
>>> 19:58:38 
>>> installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl:
>>>  
>>> file:/w/workspace/infrautils-distribution-check-oxygen/distribution/features/singles/odl-integration-compatible-with-1node/target/feature/feature.xml,
>>>  Feature: odl-integration-compatible-with-1node 0.8.0.SNAPSHOT]  Time 
>>> elapsed: 168.097 sec  <<< ERROR!
>>> 19:58:38 org.apache.karaf.features.internal.util.MultiException: Error 
>>> restarting bundles
>>> 19:58:38at 
>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:865)
>>> 19:58:38at 
>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1188)
>>> 19:58:38at 
>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1086)
>>> 19:58:38at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> 19:58:38at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> 19:58:38at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> 19:58:38at java.lang.Thread.run(Thread.java:748)
>>> 19:58:38Suppressed: org.osgi.framework.BundleException: Exception in 
>>> org.opendaylight.netconf.tcp.osgi.NetconfTCPActivator.start() of bundle 
>>> org.opendaylight.netconf.tcp.
>>> 19:58:38at 
>>> org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792)
>>> 19:58:38at 
>>> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
>>> 19:58:38at 
>>> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)
>>> 19:58:38at 
>>> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)
>>> 19:58:38at 
>>> org.eclipse.osgi.container.Module.doStart(Module.java:571)
>>> 19:58:38at 
>>> org.eclipse.osgi.container.Module.start(Module.java:439)
>>> 19:58:38at 
>>> org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:392)
>>> 19:58:38at 
>>> org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:411)
>>> 19:58:38at 
>>> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1299)
>>> 19:58:38at 
>>> org.apache.karaf

Re: [openflowplugin-dev] [integration-dev] SFT failures in distribution-check

[Luis Gomez]

Problem is hard coded feature + bundle version in this patch that is also in 
master branch.

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


I will file a patch today for this if nobody does before.

PS- This should be one of these corner cases our distribution-check cannot 
detect before the patch is actually merged.

BR/Luis



> On Oct 26, 2017, at 1:19 PM, Tom Pantelis  wrote:
> 
> Hello,
> 
> Anybody know what's changed today to cause this failure (it's happening every 
> time so not intermittent) - 
> https://jenkins.opendaylight.org/releng/job/infrautils-distribution-check-oxygen/159/console
>  
> 
> 
> 19:58:38 Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
> 170.206 sec <<< FAILURE! - in 
> org.opendaylight.odlparent.featuretest.SingleFeatureTest
> 19:58:38 
> installFeatureCatchAndLog(org.opendaylight.odlparent.featuretest.SingleFeatureTest)[repoUrl:
>  
> file:/w/workspace/infrautils-distribution-check-oxygen/distribution/features/singles/odl-integration-compatible-with-1node/target/feature/feature.xml,
>  Feature: odl-integration-compatible-with-1node 0.8.0.SNAPSHOT]  Time 
> elapsed: 168.097 sec  <<< ERROR!
> 19:58:38 org.apache.karaf.features.internal.util.MultiException: Error 
> restarting bundles
> 19:58:38  at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:865)
> 19:58:38  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1188)
> 19:58:38  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1086)
> 19:58:38  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 19:58:38  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 19:58:38  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 19:58:38  at java.lang.Thread.run(Thread.java:748)
> 19:58:38  Suppressed: org.osgi.framework.BundleException: Exception in 
> org.opendaylight.netconf.tcp.osgi.NetconfTCPActivator.start() of bundle 
> org.opendaylight.netconf.tcp.
> 19:58:38  at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792)
> 19:58:38  at 
> org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
> 19:58:38  at 
> org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)
> 19:58:38  at 
> org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)
> 19:58:38  at 
> org.eclipse.osgi.container.Module.doStart(Module.java:571)
> 19:58:38  at 
> org.eclipse.osgi.container.Module.start(Module.java:439)
> 19:58:38  at 
> org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:392)
> 19:58:38  at 
> org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:411)
> 19:58:38  at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1299)
> 19:58:38  at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:857)
> 19:58:38  ... 6 more
> 19:58:38  Caused by: java.net.BindException: Address already in use
> 19:58:38  at sun.nio.ch.Net.bind0(Native Method)
> 19:58:38  at sun.nio.ch.Net.bind(Net.java:433)
> 19:58:38  at sun.nio.ch.Net.bind(Net.java:425)
> 19:58:38  at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 
> Also controller and mdsal distribution-checks are failing for a different 
> reason:
> 
> 18:28:23 [ERROR] Failed to execute goal on project features-index: Could not 
> resolve dependencies for project 
> org.opendaylight.integration:features-index:feature:0.8.0-SNAPSHOT: Failed to 
> collect dependencies at 
> org.opendaylight.openflowplugin:features-openflowplugin:xml:features:0.6.0-SNAPSHOT
>  -> 
> org.opendaylight.openflowplugin:odl-openflowplugin-app-southbound-cli:xml:features:1.0.0-SNAPSHOT
>  -> 
> org.opendaylight.openflowplugin.applications:southbound-cli:jar:0.5.1-SNAPSHOT:
>  Failed to read artifact descriptor for 
> org.opendaylight.openflowplugin.applications:southbound-cli:jar:0.5.1-SNAPSHOT:
>  Could not find artifact 
> org.opendaylight.controller:config-artifacts:pom:0.7.1-SNAPSHOT in 
> file-snapshots (file:///tmp/n/ <>) -> [Help 1]
> 
> 
> 
> Tom
> ___
> integration-dev mailing list
> integration-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/integration-dev

___
openflowplugin-dev mailing list

Re: [openflowplugin-dev] Clean & Rename ofp csit job

[Luis Gomez]

Unfortunately I do not think jenkins supports sub-tabs, I could ask LF for 3 
new tabs: openflowplugin-carbon, openflowplugin-nitrogen, and 
openflowplugin-oxygen, is this still good?

> On Oct 16, 2017, at 12:28 PM, Anil Vishnoi <vishnoia...@gmail.com> wrote:
> 
> Thanks Luis,
> 
> I was wondering if it's possible to have 3 more tables under openflowplugin 
> tab that can show all the oxygen/nitrogen/carbon jobs in separate tabs. It's 
> easy to see the state of all the jobs of specific release in that kind of 
> view.
> 
> On Mon, Oct 16, 2017 at 12:22 PM, Luis Gomez <ece...@gmail.com> wrote:
> Hi ofp devs,
> 
> We have just merged a patch to clean and rename ofp csit jobs [1]:
> 
> https://jenkins.opendaylight.org/releng/view/openflowplugin/
> 
> If you see anything unusual please let me know.
> 
> [1] https://git.opendaylight.org/gerrit/#/c/64227/
> 
> ___
> openflowplugin-dev mailing list
> 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] Clean & Rename ofp csit job

[Luis Gomez]

Hi ofp devs,

We have just merged a patch to clean and rename ofp csit jobs [1]:

https://jenkins.opendaylight.org/releng/view/openflowplugin/ 


If you see anything unusual please let me know.

[1] https://git.opendaylight.org/gerrit/#/c/64227/ 
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Re: [openflowplugin-dev] [integration-dev] [releng/builder] Issue with mininet-ovs-25 VM

[Luis Gomez]

Hi Anil, OVS has never been a problem until a couple of days ago so I agree 
some investigation is required, maybe a new VM spin is faster as OF test is 
blocked by this now.

BR/Luis


> On Oct 13, 2017, at 4:31 AM, Anil Belur <abe...@linuxfoundation.org> wrote:
> 
> Helllo Luis:
> 
> After starting a VM (Ubuntu 16.04, mininnet-ovs-25), the logs show the same 
> that the daemon is not available.
> 
> 
> # cat /var/log/openvswitch/ovs-vswitchd.log 
> 2017-10-13T11:01:03.646Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>  connected 
> 2017-10-13T11:01:03.648Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.5.2 
> 2017-10-13T11:01:04.150Z|2|daemon_unix(monitor)|INFO|pid 3691 died, exit 
> status 0, exiting 
> 
> # cat /var/log/openvswitch/ovsdb-server.log 
> 2017-10-13T11:01:03.636Z|2|ovsdb_server|INFO|ovsdb-server (Open vSwitch) 
> 2.5.2 
> 2017-10-13T11:01:04.152Z|2|daemon_unix(monitor)|INFO|pid 3681 died, exit 
> status 0, exiting
> 
> However, you can see that the service is still running?
> # service openvswitch-switch status  
> ● openvswitch-switch.service - Open vSwitch 
>   Loaded: loaded (/lib/systemd/system/openvswitch-switch.service; enabled; 
> vendor preset: enabled) 
>   Active: active (exited) since Fri 2017-10-13 11:01:03 UTC; 2min 40s ago 
> Main PID: 3698 (code=exited, status=0/SUCCESS) 
>Tasks: 0 
>   Memory: 0B 
>  CPU: 0 
>   CGroup: /system.slice/openvswitch-switch.service 
> 
> Oct 13 11:01:03 abelur-test-mininet-ovs-25 systemd[1]: Starting Open 
> vSwitch... 
> Oct 13 11:01:03 abelur-test-mininet-ovs-25 systemd[1]: Started Open vSwitch. 
> 
> After restarting the openvswitch-switch service the logs looks bit different. 
> 
> # tailf /var/log/openvswitch/ovsdb-server.log 
> ...
> 2017-10-13T11:01:04.152Z|2|daemon_unix(monitor)|INFO|pid 3681 died, exit 
> status 0, exiting 
> 2017-10-13T11:08:38.830Z|1|vlog|INFO|opened log file 
> /var/log/openvswitch/ovsdb-server.log 
> 2017-10-13T11:08:38.832Z|2|ovsdb_server|INFO|ovsdb-server (Open vSwitch) 
> 2.5.2 
> 
> # tailf /var/log/openvswitch/ovs-vswitchd.log 
> ..
> 2017-10-13T11:08:38.840Z|1|vlog|INFO|opened log file 
> /var/log/openvswitch/ovs-vswitchd.log 
> 2017-10-13T11:08:38.841Z|2|ovs_numa|INFO|Discovered 2 CPU cores on NUMA 
> node 0 
> 2017-10-13T11:08:38.841Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and 2 
> CPU cores 
> 2017-10-13T11:08:38.841Z|4|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>  connecting... 
> 2017-10-13T11:08:38.841Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>  connected 
> 2017-10-13T11:08:38.843Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.5.2
> 
> Is it a requirement to restart OVS post install? If required, we can build a 
> new image for `mininet-ovs-25` or alternatively we can temporarily prefix the 
> scripts to restart OVS similar to the below command?
> 
> `sudo service openvswitch-switch restart`
> 
> Also Job number #12 has passed two days ago, I don't think anything changed 
> on VM after that, it would be a good idea to investigate what has changed in 
> the last 2 days causing 1node sanity tests to fail.
> 
> Probably Thanh should be up by now, if we need to build a new image or will 
> check the status morning in a few hours and build a new image.
> 
> [1.] 
> https://jenkins.opendaylight.org/releng/view/Sanity-Jobs/job/openflowplugin-csit-1node-sanity-only-oxygen/12/
>  
> <https://jenkins.opendaylight.org/releng/view/Sanity-Jobs/job/openflowplugin-csit-1node-sanity-only-oxygen/12/>
>  
> 
> Thanks,
> Anil
> 
> 
> 
> On Fri, Oct 13, 2017 at 5:31 PM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> Hi Anil,
> 
> I added some log printout for the VM and it seems the OVS dies 3.5 minutes 
> after it is started, can you please bring manually 1 VM and verify why is 
> this happening?
> 
> sudo cat /var/log/openvswitch/ovs-vswitchd.log
> 2017-10-13T07:05:17.896Z|1|vlog|INFO|opened log file 
> /var/log/openvswitch/ovs-vswitchd.log
> 2017-10-13T07:05:17.948Z|2|ovs_numa|INFO|Discovered 2 CPU cores on NUMA 
> node 0
> 2017-10-13T07:05:17.948Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and 2 
> CPU cores
> 2017-10-13T07:05:17.948Z|4|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>  connecting...
> 2017-10-13T07:05:17.948Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
>  connected
> 2017-10-13T07:05:17.950Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.5.2
> 2017-10-13T07:08:39.345Z|7|memory|INFO|8268 kB peak resident set size 
> after 201.4 seconds
> 2017-

Re: [openflowplugin-dev] [integration-dev] [releng/builder] Issue with mininet-ovs-25 VM

[Luis Gomez]

Hi Anil,

I added some log printout for the VM and it seems the OVS dies 3.5 minutes 
after it is started, can you please bring manually 1 VM and verify why is this 
happening?

sudo cat /var/log/openvswitch/ovs-vswitchd.log
2017-10-13T07:05:17.896Z|1|vlog|INFO|opened log file 
/var/log/openvswitch/ovs-vswitchd.log
2017-10-13T07:05:17.948Z|2|ovs_numa|INFO|Discovered 2 CPU cores on NUMA 
node 0
2017-10-13T07:05:17.948Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and 2 CPU 
cores
2017-10-13T07:05:17.948Z|4|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connecting...
2017-10-13T07:05:17.948Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connected
2017-10-13T07:05:17.950Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.5.2
2017-10-13T07:08:39.345Z|7|memory|INFO|8268 kB peak resident set size after 
201.4 seconds
2017-10-13T07:08:39.347Z|2|daemon_unix(monitor)|INFO|pid 1647 died, exit 
status 0, exiting
2017-10-13T07:09:08.300Z|1|vlog|INFO|opened log file 
/var/log/openvswitch/ovs-vswitchd.log
2017-10-13T07:09:08.301Z|2|ovs_numa|INFO|Discovered 2 CPU cores on NUMA 
node 0
2017-10-13T07:09:08.301Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and 2 CPU 
cores
2017-10-13T07:09:08.301Z|4|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connecting...
2017-10-13T07:09:08.302Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connected
2017-10-13T07:09:08.304Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.5.2
2017-10-13T07:09:09.089Z|2|daemon_unix(monitor)|INFO|pid 4938 died, exit 
status 0, exiting

/var/log/openvswitch/ovsdb-server.log
017-10-13T07:05:17.703Z|1|vlog|INFO|opened log file 
/var/log/openvswitch/ovsdb-server.log
2017-10-13T07:05:17.709Z|2|ovsdb_server|INFO|ovsdb-server (Open vSwitch) 
2.5.2
2017-10-13T07:05:27.715Z|3|memory|INFO|3456 kB peak resident set size after 
10.0 seconds
2017-10-13T07:05:27.715Z|4|memory|INFO|cells:16 monitors:1 sessions:1
2017-10-13T07:08:39.349Z|2|daemon_unix(monitor)|INFO|pid 1594 died, exit 
status 0, exiting
2017-10-13T07:09:08.285Z|1|vlog|INFO|opened log file 
/var/log/openvswitch/ovsdb-server.log
2017-10-13T07:09:08.288Z|2|ovsdb_server|INFO|ovsdb-server (Open vSwitch) 
2.5.2
2017-10-13T07:09:09.191Z|2|daemon_unix(monitor)|INFO|pid 4928 died, exit 
status 0, exiting

FYI The test starts at 07:10:19 and by then the OVS is not available.

Thanks/Luis


> On Oct 12, 2017, at 8:48 PM, Anil Belur <abe...@linuxfoundation.org> wrote:
> 
> 
> 
> On Fri, Oct 13, 2017 at 6:32 AM, Luis Gomez <ece...@gmail.com> wrote:
> FYI, since yesterday OF csit jobs are failing:
> 
> https://jenkins.opendaylight.org/releng/view/Sanity-Jobs/job/openflowplugin-csit-1node-sanity-only-oxygen/
> 
> Looking at the robot log, it seems like OVS is not installed in 
> mininet-ovs-25 VM:
> 
> *** Creating network
> *** Adding controller
> *** Adding hosts:
> h1 h2 h3 h4
> *** Adding switches:
> ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No 
> such file or directory)
> ovs-vsctl exited with code 1
> *** Error connecting to ovs-db with ovs-vsctl
> Make sure that Open vSwitch is installed, that ovsdb-server is running, and 
> that
> "ovs-vsctl show" works correctly.
> You may wish to try "service openvswitch-switch start".
> [jenkins@releng-09818-14-1-mininet-ovs-25-0 ~]>
> 
> 
> Has anything changed lately in this VM?
> 
> 
> 
> Luis, Nothing has changed recently on the VM images, from the logs in [1.] 
> shows OVS install is going through while these images were updates during 
> September.
> 
> [1.] 
> https://logs.opendaylight.org/releng/jenkins092/builder-packer-merge-ubuntu-16.04-mininet-ovs-2.5/6/
>  
> 
> Thanks,
> Anil
> public_cloud: ---> Install OpenVSwitch 2.5.0
> public_cloud: Get:1 
> http://security.ubuntu.com/ubuntu
>  xenial-security InRelease [102 kB]
> public_cloud: Hit:2 
> http://us.archive.ubuntu.com/ubuntu
>  xenial InRelease
> public_cloud: Hit:3 
> http://rackspace.clouds.archive.ubuntu.com/ubuntu
>  xenial InRelease
> public_cloud: Get:4 
> http://rackspace.clouds.archive.ubuntu.com/ubuntu
>  xenial-updates InRelease [102 kB]
> public_cloud: Get:5 
> http://rackspace.clouds.archive.ubuntu.com/ubuntu
>  xenial-backports InRelease [102 kB]
> public_cloud: Ign:6 
> http://apt.puppetlabs.com
>  xenial InRelease
> private_cloud: mv -f 
> thrift/parse/.deps/thrift_thrift_bootstrap-t_typedef.Tpo 
> thrift/parse/.deps/thrift_thrift_bootstrap-t_typedef.Po
> private_cloud: g++ -DHAVE_CONFIG_H -I. -I../../.. 
> -I../../../lib/cpp/src/thrift -I../../../lib/c_glib/src/thrift-Wall 
> -Wextra -pedantic -g -O2 -std=c++11 -MT 
> thrift/parse/thrift_thrift_bootstrap-parse.o -MD -MP -MF 
> thrift/p

[openflowplugin-dev] [releng/builder] Issue with mininet-ovs-25 VM

[Luis Gomez]

FYI, since yesterday OF csit jobs are failing:

https://jenkins.opendaylight.org/releng/view/Sanity-Jobs/job/openflowplugin-csit-1node-sanity-only-oxygen/

Looking at the robot log, it seems like OVS is not installed in mininet-ovs-25 
VM:

*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2 h3 h4 
*** Adding switches:
ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No 
such file or directory)
ovs-vsctl exited with code 1
*** Error connecting to ovs-db with ovs-vsctl
Make sure that Open vSwitch is installed, that ovsdb-server is running, and that
"ovs-vsctl show" works correctly.
You may wish to try "service openvswitch-switch start".
[jenkins@releng-09818-14-1-mininet-ovs-25-0 ~]>


Has anything changed lately in this VM?

BR/Luis


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

Re: [openflowplugin-dev] hitless resync

[Luis Gomez]

I have few questions on this feature:

- Is this feature enabled by default?
- Which OVS version supports bundles? I believe we currently use 2.5.2 in 
latest tools VM
- How do we activate bundle programming? is it enough to push a bunch of 
flows/group to FRM using REST?
- How do we verify this feature? is there a way to check bundle programming has 
really happened?

BR/Luis


> On Oct 12, 2017, at 10:26 AM, Anil Vishnoi <vishnoia...@gmail.com> wrote:
> 
> No, there is no CSIT test for bundles.
> 
> On Thu, Oct 12, 2017 at 10:15 AM, Jamo Luhrsen <jluhr...@gmail.com 
> <mailto:jluhr...@gmail.com>> wrote:
> it's the thing that uses openflow bundles. I didn't follow the dev cycle
> with it, but I get the sense that it works now.
> 
> https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Hitless_resync
>  
> <https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Hitless_resync>
> 
> JamO
> 
> On 10/12/2017 10:04 AM, Luis Gomez wrote:
> > What is hitless resync in the OF plugin context?
> >
> >> On Oct 12, 2017, at 8:22 AM, Jamo Luhrsen <jluhr...@gmail.com 
> >> <mailto:jluhr...@gmail.com>> wrote:
> >>
> >> Hi OFP,
> >>
> >> We talked a little about this hitless resync feature from openflowplugin. 
> >> It's of
> >> interest to netvirt. I'm wondering if there are any CSIT jobs that 
> >> validate it in
> >> the openflowplugin CSIT jobs?
> >>
> >> We'll be adding some netvirt test cases that will also test it, but just 
> >> from a
> >> higher level than maybe it would be tested at your level.
> >>
> >> Thanks,
> >> JamO
> >
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> <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] Fwd: Carbon issues

[Luis Gomez]

FYI issues 1) and 3) are currently blocking Carbon SR2.

> Begin forwarded message:
> 
> From: Luis Gomez <ece...@gmail.com>
> Subject: Carbon issues
> Date: October 3, 2017 at 7:22:40 PM PDT
> To: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
> 
> Hi all,
> 
> This is list of issues I see in Carbon branch:
> 
> 1) Cbench test does not work anymore:
> https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-periodic-cbench-daily-only-carbon/
> 
> This was introduced after this patch:
> https://git.opendaylight.org/gerrit/#/c/59557/
> 
> And it seems we forgot to cherry-picked nitrogen fix:
> https://git.opendaylight.org/gerrit/#/c/62775
> 
> So I reopened the bug:
> https://bugs.opendaylight.org/show_bug.cgi?id=9088
> 
> 2)  Controller fails to delete 100K flows from switches
> https://bugs.opendaylight.org/show_bug.cgi?id=8787
> 
> This is failing in all branches now, there are some candidate patches but my 
> reading from the comments is that these need more work.
> 
> 3) Member isolation issue in cluster:
> https://bugs.opendaylight.org/show_bug.cgi?id=9145
> 
> There is also a candidate patch but nothing merged for now.
> 
> 4) Sporadic cluster issues:
> https://bugs.opendaylight.org/show_bug.cgi?id=9006
> 
> It is not clear whether this is controller or test env issue, more 
> investigation is required.
> 
> BR/Luis
> 

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

Re: [openflowplugin-dev] [release] ofp merge job unstable

[Luis Gomez]

Thats OK Thanh, something I do not understand is the unit test that fails in 
the merge job does not fail in the integration and the verify jobs that also 
build the master branch head.

> On Oct 5, 2017, at 9:17 AM, Thanh Ha <thanh...@linuxfoundation.org> wrote:
> 
> On Wed, Oct 4, 2017 at 10:49 PM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> So I just checked and artifacts are actually being deployed:
> 
> https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/openflowplugin/odl-openflowplugin-flow-services/0.6.0-SNAPSHOT/
>  
> <https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/openflowplugin/odl-openflowplugin-flow-services/0.6.0-SNAPSHOT/>
> 
> I do not think this was like this before, has anything changed in the merge 
> jobs definition?
> 
> Hi Luis,
> 
> I should have mentioned I forced a push because it was blocking yangtools 
> 1.2.0 bumping and I didn't want to delay fixing the oxygen branch as folks 
> were trying to get work done.
> 
> Regards,
> Thanh
> 

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

Re: [openflowplugin-dev] [release] CSIT jobs with IGNORE status or no activity to resolve

[Luis Gomez]

Fair enough, we can wait until that.

> On Oct 5, 2017, at 10:24 AM, Abhijit Kumbhare <abhijitk...@gmail.com> wrote:
> 
> I think we should discuss the FRS at the DDF in a small OFP breakout - and 
> probably beyond in the next OFP meeting and then decide.
> 
> On Thu, Oct 5, 2017 at 10:08 AM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> My question is simple, will OFP devs look and fix FRS related bugs? if yes we 
> can restore the FRS jobs, if not I think we are waisting resources.
> 
> 
>> On Oct 5, 2017, at 1:27 AM, Anil Vishnoi <vishnoia...@gmail.com 
>> <mailto:vishnoia...@gmail.com>> wrote:
>> 
>> I would suggest atleast we should open a bug for all the issues. 
>> 
>> Given that these jobs are remove, how do we verify that the job passes with 
>> the new fixes ? Is there any way we can trigger these jobs ?
>> 
>> On Tue, Oct 3, 2017 at 7:28 PM, Luis Gomez <ece...@gmail.com 
>> <mailto:ece...@gmail.com>> wrote:
>> OK, we do not want to use unnecessary resources so here is the patch: 
>> https://git.opendaylight.org/gerrit/#/c/63927/ 
>> <https://git.opendaylight.org/gerrit/#/c/63927/>
>> 
>> We can always revert if anybody wants to support FRS in future.
>> 
>> BR/Luis
>> 
>> 
>>> On Sep 29, 2017, at 10:57 AM, Luis Gomez <ece...@gmail.com 
>>> <mailto:ece...@gmail.com>> wrote:
>>> 
>>> Hi ofp devs,
>>> 
>>> We have been marking FRS tests IGNORE for a while because this 
>>> functionality has never been stable, my question is should we: 1) remove 
>>> these jobs as suggested by this mail or 2) open bugs and fix FRS given we 
>>> have people for this.
>>> 
>>> BR/Luis
>>> 
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: Jamo Luhrsen <jluhr...@gmail.com <mailto:jluhr...@gmail.com>>
>>>> Subject: [release] CSIT jobs with IGNORE status or no activity to resolve
>>>> Date: September 29, 2017 at 9:47:48 AM PDT
>>>> To: Release <rele...@lists.opendaylight.org 
>>>> <mailto:rele...@lists.opendaylight.org>>, 
>>>> "integration-...@lists.opendaylight.org 
>>>> <mailto:integration-...@lists.opendaylight.org>" 
>>>> <integration-...@lists.opendaylight.org 
>>>> <mailto:integration-...@lists.opendaylight.org>>
>>>> 
>>>> Hi all,
>>>> 
>>>> Every release now (including SRs) we have one step to validate
>>>> CSIT status. It's becoming very common for projects just to quickly mark 
>>>> their
>>>> failing jobs as IGNORE or OKAY without providing any bug id or notes
>>>> about progress to resolve the failures.
>>>> 
>>>> There are probably several reasons projects do this, but the end result is 
>>>> that
>>>> these jobs are not providing any value and just taking up valuable 
>>>> resources.
>>>> 
>>>> We would like to start removing all jobs that go two releases in this same
>>>> state.
>>>> 
>>>> Having jobs with failures is ok. But those failures should be associated 
>>>> with
>>>> some bug and/or some activity to resolve the failures.
>>>> 
>>>> We can start this process with the Oxygen release in March, using 
>>>> Nitrogen's
>>>> status [0] unless there are objections.
>>>> 
>>>> Of course, each project would be notified prior to job removal, but the 
>>>> goal is
>>>> to remove this overhead of investigating the same project CSIT failures. I
>>>> took the liberty to do this already for SNMP [1].
>>>> 
>>>> Thanks,
>>>> JamO
>>>> 
>>>> [0] 
>>>> https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1568731761
>>>>  
>>>> <https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1568731761>
>>>> [1] https://git.opendaylight.org/gerrit/#/q/topic:remove-snmp-csit 
>>>> <https://git.opendaylight.org/gerrit/#/q/topic:remove-snmp-csit>
>>>> ___
>>>> release mailing list
>>>> rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>
>>>> https://lists.opendaylight.org/mailman/listinfo/release 
>>>> <https://lists.opendaylight.org/mailman/listinfo/release>
>>> 
>> 
>> 
>> ___
>> openflowplugin-dev mailing list
>> openflowplugin-dev@lists.opendaylight.org 
>> <mailto:openflowplugin-dev@lists.opendaylight.org>
>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
>> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev>
>> 
>> 
>> 
>> 
>> -- 
>> Thanks
>> Anil
> 
> 
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> <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] CSIT jobs with IGNORE status or no activity to resolve

[Luis Gomez]

My question is simple, will OFP devs look and fix FRS related bugs? if yes we 
can restore the FRS jobs, if not I think we are waisting resources.


> On Oct 5, 2017, at 1:27 AM, Anil Vishnoi <vishnoia...@gmail.com> wrote:
> 
> I would suggest atleast we should open a bug for all the issues. 
> 
> Given that these jobs are remove, how do we verify that the job passes with 
> the new fixes ? Is there any way we can trigger these jobs ?
> 
> On Tue, Oct 3, 2017 at 7:28 PM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> OK, we do not want to use unnecessary resources so here is the patch: 
> https://git.opendaylight.org/gerrit/#/c/63927/ 
> <https://git.opendaylight.org/gerrit/#/c/63927/>
> 
> We can always revert if anybody wants to support FRS in future.
> 
> BR/Luis
> 
> 
>> On Sep 29, 2017, at 10:57 AM, Luis Gomez <ece...@gmail.com 
>> <mailto:ece...@gmail.com>> wrote:
>> 
>> Hi ofp devs,
>> 
>> We have been marking FRS tests IGNORE for a while because this functionality 
>> has never been stable, my question is should we: 1) remove these jobs as 
>> suggested by this mail or 2) open bugs and fix FRS given we have people for 
>> this.
>> 
>> BR/Luis
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Jamo Luhrsen <jluhr...@gmail.com <mailto:jluhr...@gmail.com>>
>>> Subject: [release] CSIT jobs with IGNORE status or no activity to resolve
>>> Date: September 29, 2017 at 9:47:48 AM PDT
>>> To: Release <rele...@lists.opendaylight.org 
>>> <mailto:rele...@lists.opendaylight.org>>, 
>>> "integration-...@lists.opendaylight.org 
>>> <mailto:integration-...@lists.opendaylight.org>" 
>>> <integration-...@lists.opendaylight.org 
>>> <mailto:integration-...@lists.opendaylight.org>>
>>> 
>>> Hi all,
>>> 
>>> Every release now (including SRs) we have one step to validate
>>> CSIT status. It's becoming very common for projects just to quickly mark 
>>> their
>>> failing jobs as IGNORE or OKAY without providing any bug id or notes
>>> about progress to resolve the failures.
>>> 
>>> There are probably several reasons projects do this, but the end result is 
>>> that
>>> these jobs are not providing any value and just taking up valuable 
>>> resources.
>>> 
>>> We would like to start removing all jobs that go two releases in this same
>>> state.
>>> 
>>> Having jobs with failures is ok. But those failures should be associated 
>>> with
>>> some bug and/or some activity to resolve the failures.
>>> 
>>> We can start this process with the Oxygen release in March, using Nitrogen's
>>> status [0] unless there are objections.
>>> 
>>> Of course, each project would be notified prior to job removal, but the 
>>> goal is
>>> to remove this overhead of investigating the same project CSIT failures. I
>>> took the liberty to do this already for SNMP [1].
>>> 
>>> Thanks,
>>> JamO
>>> 
>>> [0] 
>>> https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1568731761
>>>  
>>> <https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1568731761>
>>> [1] https://git.opendaylight.org/gerrit/#/q/topic:remove-snmp-csit 
>>> <https://git.opendaylight.org/gerrit/#/q/topic:remove-snmp-csit>
>>> ___
>>> release mailing list
>>> rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org>
>>> https://lists.opendaylight.org/mailman/listinfo/release 
>>> <https://lists.opendaylight.org/mailman/listinfo/release>
>> 
> 
> 
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org 
> <mailto:openflowplugin-dev@lists.opendaylight.org>
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> <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] [release] ofp merge job unstable

[Luis Gomez]

So I just checked and artifacts are actually being deployed:

https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/openflowplugin/odl-openflowplugin-flow-services/0.6.0-SNAPSHOT/
 
<https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/openflowplugin/odl-openflowplugin-flow-services/0.6.0-SNAPSHOT/>

I do not think this was like this before, has anything changed in the merge 
jobs definition?


> On Sep 29, 2017, at 10:24 AM, Luis Gomez <ece...@gmail.com> wrote:
> 
> It looks like it has couple of unit tests failing:
> 
> https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-merge-oxygen/69/testReport/
>  
> <https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-merge-oxygen/69/testReport/>
> 
> 
>> On Sep 29, 2017, at 10:17 AM, Thanh Ha <thanh...@linuxfoundation.org 
>> <mailto:thanh...@linuxfoundation.org>> wrote:
>> 
>> Hi Everyone,
>> 
>> The OpenFlowPlugin Oxygen merge job has been unstable since September 18th 
>> [0] and needs to be resolved as unstable jobs do not push artifacts to 
>> Nexus. Can someone fix the test failures so that the merge job can pass?
>> 
>> Thanks,
>> Thanh
>> 
>> [0] https://jenkins.opendaylight.org/releng/job/openflowplugin-merge-oxygen/ 
>> <https://jenkins.opendaylight.org/releng/job/openflowplugin-merge-oxygen/>___
>> release mailing list
>> rele...@lists.opendaylight.org <mailto: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] [release] CSIT jobs with IGNORE status or no activity to resolve

[Luis Gomez]

OK, we do not want to use unnecessary resources so here is the patch: 
https://git.opendaylight.org/gerrit/#/c/63927/ 
<https://git.opendaylight.org/gerrit/#/c/63927/>

We can always revert if anybody wants to support FRS in future.

BR/Luis


> On Sep 29, 2017, at 10:57 AM, Luis Gomez <ece...@gmail.com> wrote:
> 
> Hi ofp devs,
> 
> We have been marking FRS tests IGNORE for a while because this functionality 
> has never been stable, my question is should we: 1) remove these jobs as 
> suggested by this mail or 2) open bugs and fix FRS given we have people for 
> this.
> 
> BR/Luis
> 
> 
>> Begin forwarded message:
>> 
>> From: Jamo Luhrsen <jluhr...@gmail.com <mailto:jluhr...@gmail.com>>
>> Subject: [release] CSIT jobs with IGNORE status or no activity to resolve
>> Date: September 29, 2017 at 9:47:48 AM PDT
>> To: Release <rele...@lists.opendaylight.org 
>> <mailto:rele...@lists.opendaylight.org>>, 
>> "integration-...@lists.opendaylight.org 
>> <mailto:integration-...@lists.opendaylight.org>" 
>> <integration-...@lists.opendaylight.org 
>> <mailto:integration-...@lists.opendaylight.org>>
>> 
>> Hi all,
>> 
>> Every release now (including SRs) we have one step to validate
>> CSIT status. It's becoming very common for projects just to quickly mark 
>> their
>> failing jobs as IGNORE or OKAY without providing any bug id or notes
>> about progress to resolve the failures.
>> 
>> There are probably several reasons projects do this, but the end result is 
>> that
>> these jobs are not providing any value and just taking up valuable resources.
>> 
>> We would like to start removing all jobs that go two releases in this same
>> state.
>> 
>> Having jobs with failures is ok. But those failures should be associated with
>> some bug and/or some activity to resolve the failures.
>> 
>> We can start this process with the Oxygen release in March, using Nitrogen's
>> status [0] unless there are objections.
>> 
>> Of course, each project would be notified prior to job removal, but the goal 
>> is
>> to remove this overhead of investigating the same project CSIT failures. I
>> took the liberty to do this already for SNMP [1].
>> 
>> Thanks,
>> JamO
>> 
>> [0] 
>> https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1568731761
>>  
>> <https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1568731761>
>> [1] https://git.opendaylight.org/gerrit/#/q/topic:remove-snmp-csit 
>> <https://git.opendaylight.org/gerrit/#/q/topic:remove-snmp-csit>
>> ___
>> release mailing list
>> rele...@lists.opendaylight.org <mailto: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

[openflowplugin-dev] Carbon issues

[Luis Gomez]

Hi all,

This is list of issues I see in Carbon branch:

1) Cbench test does not work anymore:
https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-csit-1node-periodic-cbench-daily-only-carbon/

This was introduced after this patch:
https://git.opendaylight.org/gerrit/#/c/59557/

And it seems we forgot to cherry-picked nitrogen fix:
https://git.opendaylight.org/gerrit/#/c/62775

So I reopened the bug:
https://bugs.opendaylight.org/show_bug.cgi?id=9088

2)  Controller fails to delete 100K flows from switches
https://bugs.opendaylight.org/show_bug.cgi?id=8787

This is failing in all branches now, there are some candidate patches but my 
reading from the comments is that these need more work.

3) Member isolation issue in cluster:
https://bugs.opendaylight.org/show_bug.cgi?id=9145

There is also a candidate patch but nothing merged for now.

4) Sporadic cluster issues:
https://bugs.opendaylight.org/show_bug.cgi?id=9006

It is not clear whether this is controller or test env issue, more 
investigation is required.

BR/Luis

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

Re: [openflowplugin-dev] [release] ofp merge job unstable

[Luis Gomez]

It looks like it has couple of unit tests failing:

https://jenkins.opendaylight.org/releng/view/openflowplugin/job/openflowplugin-merge-oxygen/69/testReport/
 



> On Sep 29, 2017, at 10:17 AM, Thanh Ha  wrote:
> 
> Hi Everyone,
> 
> The OpenFlowPlugin Oxygen merge job has been unstable since September 18th 
> [0] and needs to be resolved as unstable jobs do not push artifacts to Nexus. 
> Can someone fix the test failures so that the merge job can pass?
> 
> Thanks,
> Thanh
> 
> [0] https://jenkins.opendaylight.org/releng/job/openflowplugin-merge-oxygen/ 
> ___
> 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

[openflowplugin-dev] New bugs

[Luis Gomez]

FYI, couple of new (and critical) bugs :

https://bugs.opendaylight.org/show_bug.cgi?id=9216 - Single Layer Serialization 
breaks Select group action order
https://bugs.opendaylight.org/show_bug.cgi?id=9217 - Mininet generates NPE in 
carbon

BR/Luis

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

[openflowplugin-dev] OFP blockers

[Luis Gomez]

Hi all,

As commented this morning we have working patches for all blockers in nitrogen:

https://bugs.opendaylight.org/show_bug.cgi?id=9038 - 
https://git.opendaylight.org/gerrit/#/c/63236
https://bugs.opendaylight.org/show_bug.cgi?id=9089 - 
https://git.opendaylight.org/gerrit/#/c/63146
https://bugs.opendaylight.org/show_bug.cgi?id=9088 (new) - 
https://git.opendaylight.org/gerrit/#/c/62775

Can anyone review and do +2?

Thanks/Luis


> On Sep 13, 2017, at 8:49 PM, Kit Lou <klou.exter...@gmail.com> wrote:
> 
> 9145 and 9089 have been added to the blocker bug list in the nitrogen 
> tracking spreadsheet.
> 
> On Wed, Sep 13, 2017 at 9:29 PM, Luis Gomez <ece...@gmail.com> wrote:
> Thanks Abhijit,
> 
> FYI, I am also rising this OF bug as blocker after analyzing the issue in 
> detail:
> 
> https://bugs.opendaylight.org/show_bug.cgi?id=9089
> 
> BR/Luis
> 
> 
>> On Sep 13, 2017, at 4:07 PM, Abhijit Kumbhare <abhijitk...@gmail.com> wrote:
>> 
>> Hi MD-SAL & Kit,
>> 
>> Based on the test results, Luis has updated bug 9145 to be a blocker bug on 
>> MD-SAL. The bug is at:
>> https://bugs.opendaylight.org/show_bug.cgi?id=9145
>> 
>> It is introduced after the following patch was introduced in the MD-SAL 
>> project:
>> 
>> https://git.opendaylight.org/gerrit/#/c/62708/
>> 
>> Please update the blocking bugs list.
>> 
>> Thanks,
>> Abhijit
>> 
>> On Tue, Sep 12, 2017 at 8:00 PM, Abhijit Kumbhare <abhijitk...@gmail.com> 
>> wrote:
>> I think bug 9145 is probably more serious than bug 9088. Have not actually 
>> checked- what exactly does the member isolation test that is this failing 
>> do? Also what do you other guys think? Can you also check with Robert Varga 
>> about the MDSAL clustering change that has introduced this issue (after we 
>> have confirmed that the test is valid): 
>> https://git.opendaylight.org/gerrit/#/c/62708/
>> 
>> On Tue, Sep 12, 2017 at 5:24 PM Luis Gomez <ece...@gmail.com> wrote:
>> I already did. Also in the SR3 test I see these 2 bugs:
>> 
>> https://bugs.opendaylight.org/show_bug.cgi?id=9088
>> https://bugs.opendaylight.org/show_bug.cgi?id=9145
>> 
>> Both are recent bugs most likely introduced by (respectively):
>> 
>> https://git.opendaylight.org/gerrit/#/c/61755/
>> https://git.opendaylight.org/gerrit/#/c/62708/
>> 
>> Now the question is should we make any of these blockers?
>> 
>> BR/Luis
>> 
>> 
>> > On Sep 12, 2017, at 3:29 PM, Abhijit Kumbhare <abhijitk...@gmail.com> 
>> > wrote:
>> >
>> > I have +1'ed it. Can you also update the RC 3 test status?
>> >
>> > https://docs.google.com/spreadsheets/d/1MYyGLFWN2RzUkJl8XMzXQ-3zWuOrUCQpIS6ORbmf4_U/edit#gid=1968173395
>> >
>> >
>> > On Tue, Sep 12, 2017 at 8:27 AM, Abhijit Kumbhare <abhijitk...@gmail.com> 
>> > wrote:
>> > Thanks Tomas!
>> >
>> > On Tue, Sep 12, 2017 at 1:11 AM, Tomáš Slušný <tomas.slu...@pantheon.tech> 
>> > wrote:
>> > Hello Abhijit,
>> >
>> >
>> > I created Gerrit patch [0] for the release notes, so feel free to look at 
>> > it and provide comments if I forgot anything.
>> >
>> >
>> > Regards,
>> >
>> > Tomas Slusny
>> >
>> >
>> > [0]: https://git.opendaylight.org/gerrit/#/c/63019/
>> >
>> >
>> >
>> > Od: Abhijit Kumbhare <abhijitk...@gmail.com>
>> > Odoslané: utorok, 12. septembra 2017 2:57
>> > Komu: Tomáš Slušný
>> > Kópia: Anil Vishnoi; Jozef Bacigál; Shuva Jyoti Kar
>> > Predmet: Nitrogen release review notes to be done
>> >
>> > Hi Tomas,
>> >
>> > Here is the link to the release review schedule which contains links to 
>> > the release notes from different projects:
>> >
>> > https://docs.google.com/spreadsheets/d/1MYyGLFWN2RzUkJl8XMzXQ-3zWuOrUCQpIS6ORbmf4_U/edit#gid=1758798362
>> >
>> > Tracking - Nitrogen - OpenDaylight - Tabuľky Google
>> > docs.google.com
>> > Summary NITROGEN Blocker Bugs Blocker Bugs Bug ID, Summary, Responsible 
>> > Module, Reported By, Notification Email, Owner, Fix Status, Patch, 
>> > Verified By, Verify Status, Notes Blocker Bugs 8741, startup archetype 
>> > upgrade to karaf 4, controller, Ryan Goulding, Michael Vorburger, awaiting 
>> > mer...
>> >
>> >
>> >
>> > As an example you can use Genius:
>> >
>> > https://git.ope

[openflowplugin-dev] controller does not respond to ECHO requests

[Luis Gomez]

Hi OF devs,

I see this behavior in many tests but mostly in scalability/performance: When 
CPU gets busy, controller starts ignoring (i.e. not responding) switch ECHO 
requests, this makes switch disconnect and reconnect again which in most cases 
creates more CPU load in the controller and makes things worse. My question is: 
can we do something to expedite these ECHO messages? maybe handling these in 
the OF java library instead of OF plugin as Anil suggested helps but I want to 
hear others.

BR/Luis

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

Re: [openflowplugin-dev] MD-SAL Blocker bug 9145

[Luis Gomez]

Thanks Abhijit,

FYI, I am also rising this OF bug as blocker after analyzing the issue in 
detail:

https://bugs.opendaylight.org/show_bug.cgi?id=9089 
<https://bugs.opendaylight.org/show_bug.cgi?id=9089>

BR/Luis


> On Sep 13, 2017, at 4:07 PM, Abhijit Kumbhare <abhijitk...@gmail.com> wrote:
> 
> Hi MD-SAL & Kit,
> 
> Based on the test results, Luis has updated bug 9145 to be a blocker bug on 
> MD-SAL. The bug is at:
> https://bugs.opendaylight.org/show_bug.cgi?id=9145 
> <https://bugs.opendaylight.org/show_bug.cgi?id=9145>
> 
> It is introduced after the following patch was introduced in the MD-SAL 
> project:
> 
> https://git.opendaylight.org/gerrit/#/c/62708/ 
> <https://git.opendaylight.org/gerrit/#/c/62708/>
> 
> Please update the blocking bugs list.
> 
> Thanks,
> Abhijit
> 
> On Tue, Sep 12, 2017 at 8:00 PM, Abhijit Kumbhare <abhijitk...@gmail.com 
> <mailto:abhijitk...@gmail.com>> wrote:
> I think bug 9145 is probably more serious than bug 9088. Have not actually 
> checked- what exactly does the member isolation test that is this failing do? 
> Also what do you other guys think? Can you also check with Robert Varga about 
> the MDSAL clustering change that has introduced this issue (after we have 
> confirmed that the test is valid): 
> https://git.opendaylight.org/gerrit/#/c/62708/ 
> <https://git.opendaylight.org/gerrit/#/c/62708/>
> 
> On Tue, Sep 12, 2017 at 5:24 PM Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> I already did. Also in the SR3 test I see these 2 bugs:
> 
> https://bugs.opendaylight.org/show_bug.cgi?id=9088 
> <https://bugs.opendaylight.org/show_bug.cgi?id=9088>
> https://bugs.opendaylight.org/show_bug.cgi?id=9145 
> <https://bugs.opendaylight.org/show_bug.cgi?id=9145>
> 
> Both are recent bugs most likely introduced by (respectively):
> 
> https://git.opendaylight.org/gerrit/#/c/61755/ 
> <https://git.opendaylight.org/gerrit/#/c/61755/>
> https://git.opendaylight.org/gerrit/#/c/62708/ 
> <https://git.opendaylight.org/gerrit/#/c/62708/>
> 
> Now the question is should we make any of these blockers?
> 
> BR/Luis
> 
> 
> > On Sep 12, 2017, at 3:29 PM, Abhijit Kumbhare <abhijitk...@gmail.com 
> > <mailto:abhijitk...@gmail.com>> wrote:
> >
> > I have +1'ed it. Can you also update the RC 3 test status?
> >
> > https://docs.google.com/spreadsheets/d/1MYyGLFWN2RzUkJl8XMzXQ-3zWuOrUCQpIS6ORbmf4_U/edit#gid=1968173395
> >  
> > <https://docs.google.com/spreadsheets/d/1MYyGLFWN2RzUkJl8XMzXQ-3zWuOrUCQpIS6ORbmf4_U/edit#gid=1968173395>
> >
> >
> > On Tue, Sep 12, 2017 at 8:27 AM, Abhijit Kumbhare <abhijitk...@gmail.com 
> > <mailto:abhijitk...@gmail.com>> wrote:
> > Thanks Tomas!
> >
> > On Tue, Sep 12, 2017 at 1:11 AM, Tomáš Slušný <tomas.slu...@pantheon.tech> 
> > wrote:
> > Hello Abhijit,
> >
> >
> > I created Gerrit patch [0] for the release notes, so feel free to look at 
> > it and provide comments if I forgot anything.
> >
> >
> > Regards,
> >
> > Tomas Slusny
> >
> >
> > [0]: https://git.opendaylight.org/gerrit/#/c/63019/ 
> > <https://git.opendaylight.org/gerrit/#/c/63019/>
> >
> >
> >
> > Od: Abhijit Kumbhare <abhijitk...@gmail.com <mailto:abhijitk...@gmail.com>>
> > Odoslané: utorok, 12. septembra 2017 2:57
> > Komu: Tomáš Slušný
> > Kópia: Anil Vishnoi; Jozef Bacigál; Shuva Jyoti Kar
> > Predmet: Nitrogen release review notes to be done
> >
> > Hi Tomas,
> >
> > Here is the link to the release review schedule which contains links to the 
> > release notes from different projects:
> >
> > https://docs.google.com/spreadsheets/d/1MYyGLFWN2RzUkJl8XMzXQ-3zWuOrUCQpIS6ORbmf4_U/edit#gid=1758798362
> >  
> > <https://docs.google.com/spreadsheets/d/1MYyGLFWN2RzUkJl8XMzXQ-3zWuOrUCQpIS6ORbmf4_U/edit#gid=1758798362>
> >
> > Tracking - Nitrogen - OpenDaylight - Tabuľky Google
> > docs.google.com <http://docs.google.com/>
> > Summary NITROGEN Blocker Bugs Blocker Bugs Bug ID, Summary, Responsible 
> > Module, Reported By, Notification Email, Owner, Fix Status, Patch, Verified 
> > By, Verify Status, Notes Blocker Bugs 8741, startup archetype upgrade to 
> > karaf 4, controller, Ryan Goulding, Michael Vorburger, awaiting mer...
> >
> >
> >
> > As an example you can use Genius:
> >
> > https://git.opendaylight.org/gerrit/#/c/62951 
> > <https://git.opendaylight.org/gerrit/#/c/62951>
> >
> > We will ne

Re: [openflowplugin-dev] Performance regression

[Luis Gomez]

It is already in the bug :)

> On Sep 6, 2017, at 12:26 AM, Tomáš Slušný <tomas.slu...@pantheon.tech> wrote:
> 
> Hello Luis,
> 
> can you also provide INFO logs for bug 9089 too? Because from current logs I 
> really can't see what is happening there.
> 
> Thanks
> Tomas
> 
> Od: Jozef Bacigál <jozef.baci...@pantheon.tech 
> <mailto:jozef.baci...@pantheon.tech>>
> Odoslané: streda, 6. septembra 2017 8:10
> Komu: Luis Gomez
> Kópia: openflowplugin-dev
> Predmet: Re: [openflowplugin-dev] Performance regression
>  
> Thanks Luis I will check it.
> Od: Luis Gomez <ece...@gmail.com>
> Odoslané: utorok, 5. septembra 2017 21:18:02
> Komu: Jozef Bacigál
> Kópia: openflowplugin-dev
> Predmet: Re: [openflowplugin-dev] Performance regression
>  
> Hi Jozef, I just linked it in the bug.
> 
>> On Sep 4, 2017, at 12:24 AM, Jozef Bacigál <jozef.baci...@pantheon.tech 
>> <mailto:jozef.baci...@pantheon.tech>> wrote:
>> 
>> Hi Luis,
>>  
>> Please to the bug 9088, can you provide me LOG at INFO level for OFP ?
>>  
>> Jozef
>>  
>> From: Luis Gomez [mailto:ece...@gmail.com <mailto:ece...@gmail.com>] 
>> Sent: Monday, September 4, 2017 3:23 AM
>> To: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org 
>> <mailto:openflowplugin-dev@lists.opendaylight.org>>
>> Subject: [openflowplugin-dev] Performance regression
>>  
>> Hi All,
>>  
>> I went through the tests we run in CI and I observed few perf/scale 
>> regression in Carbon/Nitrogen:
>>  
>> - Carbon flow scale test: Controller cannot delete all flows after DS is 
>> cleared (old), https://bugs.opendaylight.org/show_bug.cgi?id=8787 
>> <https://bugs.opendaylight.org/show_bug.cgi?id=8787>
>> - Nitrogen flow performance test: Controller disconnects during Cbench test 
>> (new), https://bugs.opendaylight.org/show_bug.cgi?id=9088 
>> <https://bugs.opendaylight.org/show_bug.cgi?id=9088>
>> - Nitrogen/Carbon switch scale test: Controller can hardly with 100+ 
>> switches (new), https://bugs.opendaylight.org/show_bug.cgi?id=9089 
>> <https://bugs.opendaylight.org/show_bug.cgi?id=9089>
>>  
>> I am not sure if we want to make any of the above blocker, for now I set 
>> critical in case someone wants to take a look.
>>  
>> BR/Luis

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

Re: [openflowplugin-dev] Performance regression

[Luis Gomez]

Hi Jozef, I just linked it in the bug.

> On Sep 4, 2017, at 12:24 AM, Jozef Bacigál <jozef.baci...@pantheon.tech> 
> wrote:
> 
> Hi Luis,
>  
> Please to the bug 9088, can you provide me LOG at INFO level for OFP ?
>  
> Jozef
>  
> From: Luis Gomez [mailto:ece...@gmail.com] 
> Sent: Monday, September 4, 2017 3:23 AM
> To: openflowplugin-dev <openflowplugin-dev@lists.opendaylight.org>
> Subject: [openflowplugin-dev] Performance regression
>  
> Hi All,
>  
> I went through the tests we run in CI and I observed few perf/scale 
> regression in Carbon/Nitrogen:
>  
> - Carbon flow scale test: Controller cannot delete all flows after DS is 
> cleared (old), https://bugs.opendaylight.org/show_bug.cgi?id=8787 
> <https://bugs.opendaylight.org/show_bug.cgi?id=8787>
> - Nitrogen flow performance test: Controller disconnects during Cbench test 
> (new), https://bugs.opendaylight.org/show_bug.cgi?id=9088 
> <https://bugs.opendaylight.org/show_bug.cgi?id=9088>
> - Nitrogen/Carbon switch scale test: Controller can hardly with 100+ switches 
> (new), https://bugs.opendaylight.org/show_bug.cgi?id=9089 
> <https://bugs.opendaylight.org/show_bug.cgi?id=9089>
>  
> I am not sure if we want to make any of the above blocker, for now I set 
> critical in case someone wants to take a look.
>  
> BR/Luis

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

[openflowplugin-dev] Performance regression

[Luis Gomez]

Hi All,

I went through the tests we run in CI and I observed few perf/scale regression 
in Carbon/Nitrogen:

- Carbon flow scale test: Controller cannot delete all flows after DS is 
cleared (old), https://bugs.opendaylight.org/show_bug.cgi?id=8787 

- Nitrogen flow performance test: Controller disconnects during Cbench test 
(new), https://bugs.opendaylight.org/show_bug.cgi?id=9088 

- Nitrogen/Carbon switch scale test: Controller can hardly with 100+ switches 
(new), https://bugs.opendaylight.org/show_bug.cgi?id=9089 


I am not sure if we want to make any of the above blocker, for now I set 
critical in case someone wants to take a look.

BR/Luis

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

Re: [openflowplugin-dev] [controller-users] ofdpa launch not successful and controller not detecting the connected system

[Luis Gomez]

From the log I would say the connection could fail because switch does not 
handle (e.g. respond to) meter and group stats features stats messages from 
controller:

01-01 00:13:21.283817 [ofstatemanager] Unhandled message 
of_meter_features_stats _request from cxn 0.

01-01 00:13:21.283907 [ofstatemanager] Unhandled message 
of_group_features_stats_request from cxn 0.

BR/Luis


> On Aug 31, 2017, at 2:34 PM, Jamo Luhrsen  wrote:
> 
> Hi Abhilash,
> 
> 
> I added the openflowplugin-dev list here, as it seems more relevant to
> what you are trying to debug.
> 
> It seems the logs you have appended are from your switch, but I'm not
> sure anyone here will be expert in that area.
> 
> Can you look at what is happening in the OpenDaylight karaf.log when
> the connection is closed? You could also take a packet capture on
> the switch or ODL system to learn more.
> 
> at this time, all we know is that your switch's logs show that it
> sort of connected and then it was abrubtly closed. That's all we can
> tell from this email.
> 
> thanks,
> JamO
> 
> 
> On 08/21/2017 03:04 AM, Abhilash R wrote:
>> Dear Team,
>> 
>>  
>> 
>> I am trying to integrate Acton(Edgecore)5517 x86-64-accton-as5712-54x with 
>> ONL and I am stuck up as the configuration is not
>> moving ahead beyond as per the logs attached. My management IP is 
>> 192.168.3.10 and controller IP 192.168.3.3.
>> 
>>  
>> 
>> I am running ODL controlle(carbon) in the same PC connected to AC5712-54X 
>> MA1. My understanding of ODL carbon is that it
>> should detect the AS5712 MA1 automatically and it is not happening. Kindly 
>> guide me as I am a beginner in this
>> 
>>  
>> 
>> Logs appended
>> 
>>  
>> 
>> root@localhost:~# launcher ofagentapp --controller=192.168.3.3:6653 
>> --listen=192.168.3.10:6633
>> 
>> Setting up OFDPA running environment
>> 
>> ofagentapp[2689]: Start command = ofagentapp --controller=192.168.3.3:6653 
>> --listen=192.168.3.10:6633
>> 
>> 01-01 00:12:45.621455 [ofagent] version 2.0.4.0 -- Built on Mon Jan 16 2017 
>> at 0 5:17:02 UTC
>> 
>> OF Datapath ID: 0xDA7A
>> 
>> Initializing the system.
>> 
>> DMA pool size: 33554432
>> 
>> PCI unit 0: Dev 0xb854, Rev 0x03, Chip BCM56854_A2, Driver BCM56850_A0
>> 
>>  
>> 
>> Found board: as5712-54x
>> 
>> SOC unit 0 attached to PCI device BCM56854_A2
>> 
>> rc: unit 0 device BCM56854_A2
>> 
>> rc: Port modes initialized
>> 
>> rc: common SDK init complete
>> 
>> rc: platform SDK init complete
>> 
>> port_speed_1=1
>> 
>> port_speed_2=1
>> 
>> port_speed_3=1
>> 
>> port_speed_4=1
>> 
>> port_speed_5=1
>> 
>> port_speed_6=1
>> 
>> port_speed_7=1
>> 
>> port_speed_8=1
>> 
>> port_speed_9=1
>> 
>> port_speed_10=1
>> 
>> port_speed_11=1
>> 
>> port_speed_12=1
>> 
>> port_speed_13=1
>> 
>> port_speed_14=1
>> 
>> port_speed_15=1
>> 
>> port_speed_16=1
>> 
>> port_speed_17=1
>> 
>> port_speed_18=1
>> 
>> port_speed_19=1
>> 
>> port_speed_20=1
>> 
>> port_speed_21=1
>> 
>> port_speed_22=1
>> 
>> port_speed_23=1
>> 
>> port_speed_24=1
>> 
>> port_speed_25=1
>> 
>> port_speed_26=1
>> 
>> port_speed_27=1
>> 
>> port_speed_28=1
>> 
>> port_speed_29=1
>> 
>> port_speed_30=1
>> 
>> port_speed_31=1
>> 
>> port_speed_32=1
>> 
>> port_speed_33=1
>> 
>> port_speed_34=1
>> 
>> port_speed_35=1
>> 
>> port_speed_36=1
>> 
>> port_speed_37=1
>> 
>> port_speed_38=1
>> 
>> port_speed_39=1
>> 
>> port_speed_40=1
>> 
>> port_speed_41=1
>> 
>> port_speed_42=1
>> 
>> port_speed_43=1
>> 
>> port_speed_44=1
>> 
>> port_speed_45=1
>> 
>> port_speed_46=1
>> 
>> port_speed_47=1
>> 
>> port_speed_48=1
>> 
>> port_speed_49=1
>> 
>> port_speed_50=1
>> 
>> port_speed_51=1
>> 
>> port_speed_52=1
>> 
>> port_speed_53=1
>> 
>> port_speed_54=1
>> 
>> port_speed_55=1
>> 
>> port_speed_56=1
>> 
>> port_speed_57=1
>> 
>> port_speed_58=1
>> 
>> port_speed_59=1
>> 
>> port_speed_60=1
>> 
>> port_speed_61=1
>> 
>> port_speed_62=1
>> 
>> port_speed_63=1
>> 
>> port_speed_64=1
>> 
>> port_speed_65=1
>> 
>> port_speed_66=1
>> 
>> port_speed_67=1
>> 
>> port_speed_68=1
>> 
>> port_speed_69=1
>> 
>> port_speed_70=1
>> 
>> port_speed_71=1
>> 
>> port_speed_72=1
>> 
>> Starting rpcsrvTask.
>> 
>> 01-01 00:13:09.216386 [socketmanager] Initializing socket manager
>> 
>> 01-01 00:13:09.218067 [ofstatemanager] Registered gentable "test" with table 
>> id 0
>> 
>> 01-01 00:13:09.218167 [socketmanager] Enabling OF socket mgr
>> 
>> 01-01 00:13:09.218203 [ofconnectionmanager] Enabling OF connection mgr
>> 
>> 01-01 00:13:09.218243 [ofstatemanager] Enabling OF state mgr
>> 
>> 01-01 00:13:09.218281 [ofagent] Adding controller 192.168.3.3:6653
>> 
>> 01-01 00:13:09.218373 [ofconnectionmanager] Added remote connection: 
>> 

[openflowplugin-dev] Fwd: [OpenDaylight TSC] delaying Carbon-SR2?

[Luis Gomez]

Now that the branch is open again, it would be good if someone could take a 
look at this (only Carbon) bug:

https://bugs.opendaylight.org/show_bug.cgi?id=8787 


BR/Luis


> Begin forwarded message:
> 
> From: Colin Dixon 
> Subject: [OpenDaylight TSC] delaying Carbon-SR2?
> Date: August 31, 2017 at 11:12:47 AM PDT
> To: "t...@lists.opendaylight.org" 
> 
> During today's TSC call, it became clear that (at least for some of our 
> community, namely Sam and Red Hat) we can't ship SR2 in a production-ready 
> way until all the 6 bugs listed are fixed. It also became clear that the 
> spreadsheet-tracking, RC builds and locked branch seem to be distracting us 
> from other work, so staying it the "about to release" mode isn't helping.
> 
> The result is that it seems people would like to either:
> 1.) ship what we have (maybe including the 9054 patch) because it's better 
> than SR1 even if it's not better enough for many
> 2.) just open the branch and admit we'll ship Carbon-SR2 when it makes sense
> 
> During the TSC call, it sounded very much like #2 was preferable as long as 
> we get a line in the sand for when we want to ship SR2.
> 
> The result is that the branch is now open. Sam, others, thoughts on when we 
> should target SR2? I got the feeling that the timeline was less important 
> than making sure the bugs are being worked.
> 
> --Colin
> 
> ___
> 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] tests

[Luis Gomez]

Jozef, I run a second patch test and this time all test passed. The job in [3] 
failed because some negotiation issue with the second connection, so that the 
test fails because there is no connection remaining in controller:

2017-08-23 00:33:05,829 | WARN  | entLoopGroup-7-1 | HandshakeListenerImpl  
  | 279 - org.opendaylight.openflowplugin.impl - 0.5.0.SNAPSHOT | initial 
processing failed for device openflow:1

Full log: 
https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-1node-gate-flow-services-all-nitrogen/233/odl1_karaf.log.gz

BR/Luis

> On Aug 22, 2017, at 5:59 AM, Jozef Bacigál  
> wrote:
> 
> Hi Luis,
>  
> Can you please take a look at this [1] as you can see the [2] is running 
> fine, but the similar test in [3] is failing at the same test. It should test 
>  the bug 8723 [4]. But in the second suite is testing some flow add or 
> something. The double connect is running fine.
>  
> Thanks
>  
> Jozef
>  
> [1] 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-patch-test-core-nitrogen/238/
> [2] 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1node-gate-flow-services-only-nitrogen/237/
> [3] 
> https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-1node-gate-flow-services-all-nitrogen/233/
> [4] https://bugs.opendaylight.org/show_bug.cgi?id=8723

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

Re: [openflowplugin-dev] OPENFLOWPLUGIN Carbon SR2 Distribution Test Failure

[Luis Gomez]

This is just one of the cluster sporadic failures:

https://bugs.opendaylight.org/show_bug.cgi?id=9006 
<https://bugs.opendaylight.org/show_bug.cgi?id=9006>

BR/Luis


> On Aug 17, 2017, at 10:14 AM, Abhijit Kumbhare <abhijitk...@gmail.com> wrote:
> 
> Thanks Jozef & Luis!
> 
> On Thu, Aug 17, 2017 at 9:50 AM, Luis Gomez <ece...@gmail.com 
> <mailto:ece...@gmail.com>> wrote:
> Right, I do not see anything abnormal, we still have the sporadic cluster 
> test issues we have seen for some time now.
> 
>> On Aug 17, 2017, at 12:44 AM, Jozef Bacigál <jozef.baci...@pantheon.tech 
>> <mailto:jozef.baci...@pantheon.tech>> wrote:
>> 
>> The run 369 is already ok.
>> 
>> Jozef
>> Od: Abhijit Kumbhare <abhijitk...@gmail.com <mailto:abhijitk...@gmail.com>>
>> Odoslané: štvrtok, 17. augusta 2017 1:04:20
>> Komu: Jamo Luhrsen
>> Kópia: An Ho; openflowplugin-dev@lists.opendaylight.org 
>> <mailto:openflowplugin-dev@lists.opendaylight.org>
>> Predmet: Re: [openflowplugin-dev] OPENFLOWPLUGIN Carbon SR2 Distribution 
>> Test Failure
>>  
>> Yeah - I did not sign off the cluster failures.
>> 
>> On Wed, Aug 16, 2017 at 3:48 PM, Jamo Luhrsen <jluhr...@gmail.com 
>> <mailto:jluhr...@gmail.com>> wrote:
>> no, there is trouble in 3node land.
>> 
>> it's in netvirt too.
>> 
>> JamO
>> 
>> On 08/16/2017 03:40 PM, Abhijit Kumbhare wrote:
>> > Hi folks,
>> >
>> > Can you please check these out? I have signed off on a few. Most seem to 
>> > be non critical test failures. Particularly the
>> > following with 37 failures may be a bad run?
>> >
>> > https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/368/
>> >  
>> > <https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/368/>
>> >
>> > Thanks,
>> > Abhijit
>> >
>> >
>> > On Wed, Aug 16, 2017 at 10:44 AM, An Ho <an...@huawei.com 
>> > <mailto:an...@huawei.com> <mailto:an...@huawei.com 
>> > <mailto:an...@huawei.com>>> wrote:
>> >
>> > Hi OPENFLOWPLUGIN Team,
>> >
>> > __ __
>> >
>> > There are Distribution Test failures [1] in the Carbon SR2 Build 
>> > 20170815 [2] related to your project.  Please take a
>> > moment to mark these issues in the spreadsheet [1] as "OKAY" to 
>> > release or "BLOCKING" and requires a respin of Carbon
>> > SR2.
>> >
>> > __ __
>> >
>> > Best Regards,
>> >
>> > An Ho
>> >
>> > __ __
>> >
>> > [1] 
>> > https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1226505712
>> >  
>> > <https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1226505712>
>> > 
>> > <https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1226505712
>> >  
>> > <https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1226505712>>
>> >
>> > [2] 
>> > https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#SR2_Download
>> >  
>> > <https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#SR2_Download>
>> > 
>> > <https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#SR2_Download
>> >  
>> > <https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#SR2_Download>>
>> >
>> > __ __
>> >
>> > __ __
>> >
>> >
>> >
>> >
>> > ___
>> > openflowplugin-dev mailing list
>> > openflowplugin-dev@lists.opendaylight.org 
>> > <mailto:openflowplugin-dev@lists.opendaylight.org>
>> > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
>> > <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev>
>> >
>> 
>>   
>> Jozef Bacigál
>> Senior Software Engineer
>>  
>> PANTHEON technologies s.r.o.
>> Janka Kráľa 9, 974 01 Banská Bystrica
>> Slovakia
>> Tel / +421 220 665 111
>>  
>> MAIL / jozef.baci...@pantheon.tech <mailto:jozef.baci...@pantheon.tech>
>> WEB / https://pantheon.tech <https://pantheon.tech/>
>>  
>>  
>> ___
>> openflowplugin-dev mailing list
>> openflowplugin-dev@lists.opendaylight.org 
>> <mailto:openflowplugin-dev@lists.opendaylight.org>
>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
>> <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] OPENFLOWPLUGIN Carbon SR2 Distribution Test Failure

[Luis Gomez]

Right, I do not see anything abnormal, we still have the sporadic cluster test 
issues we have seen for some time now.

> On Aug 17, 2017, at 12:44 AM, Jozef Bacigál  
> wrote:
> 
> The run 369 is already ok.
> 
> Jozef
> Od: Abhijit Kumbhare >
> Odoslané: štvrtok, 17. augusta 2017 1:04:20
> Komu: Jamo Luhrsen
> Kópia: An Ho; openflowplugin-dev@lists.opendaylight.org 
> 
> Predmet: Re: [openflowplugin-dev] OPENFLOWPLUGIN Carbon SR2 Distribution Test 
> Failure
>  
> Yeah - I did not sign off the cluster failures.
> 
> On Wed, Aug 16, 2017 at 3:48 PM, Jamo Luhrsen  > wrote:
> no, there is trouble in 3node land.
> 
> it's in netvirt too.
> 
> JamO
> 
> On 08/16/2017 03:40 PM, Abhijit Kumbhare wrote:
> > Hi folks,
> >
> > Can you please check these out? I have signed off on a few. Most seem to be 
> > non critical test failures. Particularly the
> > following with 37 failures may be a bad run?
> >
> > https://jenkins.opendaylight.org/releng/job/openflowplugin-csit-3node-periodic-bulkomatic-clustering-daily-only-carbon/368/
> >  
> > 
> >
> > Thanks,
> > Abhijit
> >
> >
> > On Wed, Aug 16, 2017 at 10:44 AM, An Ho  >   > >> wrote:
> >
> > Hi OPENFLOWPLUGIN Team,
> >
> > __ __
> >
> > There are Distribution Test failures [1] in the Carbon SR2 Build 
> > 20170815 [2] related to your project.  Please take a
> > moment to mark these issues in the spreadsheet [1] as "OKAY" to release 
> > or "BLOCKING" and requires a respin of Carbon
> > SR2.
> >
> > __ __
> >
> > Best Regards,
> >
> > An Ho
> >
> > __ __
> >
> > [1] 
> > https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=1226505712
> >  
> > 
> > 
> >  >  
> > >
> >
> > [2] 
> > https://wiki.opendaylight.org/view/Simultaneous_Release:Carbon_Release_Plan#SR2_Download
> >  
> > 
> > 
> >  >  
> > >
> >
> > __ __
> >
> > __ __
> >
> >
> >
> >
> > ___
> > openflowplugin-dev mailing list
> > openflowplugin-dev@lists.opendaylight.org 
> > 
> > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev 
> > 
> >
> 
>   
> Jozef Bacigál
> Senior Software Engineer
>  
> PANTHEON technologies s.r.o.
> Janka Kráľa 9, 974 01 Banská Bystrica
> Slovakia
> Tel / +421 220 665 111
>  
> MAIL / jozef.baci...@pantheon.tech 
> WEB / https://pantheon.tech 
>  
>  
> ___
> 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