Date   

Re: OPENFLOWJAVA System Test Waiver

Jamo Luhrsen <jluhrsen@...>
 

On 05/18/2016 11:31 AM, An Ho wrote:
As indicated in their M2 Status Email [1], the OPENFLOWJAVA team would like to request a system test waiver for Boron [2]. The reason behind the
request is that openflowjava's functionality is tested by openflowplugin project which covers probably all OVS (virtual switch) supported messages /
scenarios.



Best Regards,

An Ho



[1] https://lists.opendaylight.org/pipermail/release/2016-April/006309.html

[2] https://wiki.opendaylight.org/view/Simultaneous_Release/Boron/Waiver/System_Test#OpenFlow_Protocol_Library



Re: [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Colin Dixon
 

After thinking about this for a bit, I think we have two real current problems:

1.) It's confusing for people to figure out what projects are related to OpenFlow and how.
2.) It's hard for people to bring new OpenFlow extensions to OpenDaylight because they have to start their own project.

While I think that consolidating projects under a single openflow/ namespace probably makes sense in the long run, it might be overkill since it doesn't seem required to solve the first problem and it doesn't help the second problem.

--Colin


On Fri, May 13, 2016 at 3:22 AM, Anil Vishnoi <vishnoianil@...> wrote:


On Thu, May 12, 2016 at 6:53 AM, Alexis de Talhouët <adetalhouet@...> wrote:

On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote:

So, did the TWS on this topic actually happen? I think it didn’t
Correct it didn’t, last TWS focused on phased release and semantic versioning.
, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here:

1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have.
+1, absolutely.
​+1​
 


Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand.

2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it.
+1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella.
​+1​
 


3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful.
I’m not sure to get the question here so I will at careful at further discussion.

Thanks,
Alexis

--Colin


On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote:


On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote:
On 05/09/2016 07:13 PM, Anil Vishnoi wrote:
> ​ I think this is one of the reason as well, but the higher level goal
> was to use them as a controller wide ​model and that was the reason we
> added all these models in the controller projects.

Right, but that was not really how it got marketed :) In fact it was
recognized that they are OpenFlow specific when we were deciding whether
to move them.

So was the idea to essentially define an 'OpenDaylight forwarding model'?
Let me put it in this way-- this was the real intent, but the implementation was openflow influenced ​:)

I am not quite sure how PCEP would map onto the OFP models, as there
would have to be a way to communicate the fact that things like L2
matches simply make no sense (unless some new PCEP extensions get
defined and are supported by the device)...
​...and this is one of many reason we realize lets move it to openflowplugin project :)​
 

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?
​..that's probably one way to go about it ... but it's open for thoughts 

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?
​Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not 
really 
​version ​
agnostic. 
And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). 

Bye,
Robert




-- 
Thanks
Anil

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev




--
Thanks
Anil


OPENFLOWJAVA System Test Waiver

an.ho@huawei.com
 

As indicated in their M2 Status Email [1], the OPENFLOWJAVA team would like to request a system test waiver for Boron [2].  The reason behind the request is that openflowjava's functionality is tested by openflowplugin project which covers probably all OVS (virtual switch) supported messages / scenarios.

 

Best Regards,

An Ho

 

[1] https://lists.opendaylight.org/pipermail/release/2016-April/006309.html

[2] https://wiki.opendaylight.org/view/Simultaneous_Release/Boron/Waiver/System_Test#OpenFlow_Protocol_Library

 


Re: New message count for Openflow Java in ODL master (Boron)

Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
 

Hi Michal,

 

Thanks for your reply.

Yes, I will do the changes as you have indicated.

 

Regards,

Chinmay

 

From: Michal Polkoráb [mailto:michal.polkorab@...]
Sent: Tuesday, May 17, 2016 3:14 PM
To: Chinmay Kumar Mohanta; Chinmay.Mohanta
Cc: openflowjava-dev@...; Shuva Jyoti Kar; Ashutosh Bisht; Muthukumaran K
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Chinmay,

 

in that case please go ahead with your changes. You can also remove the two positive counters mentioned before to further improve the performance (we will still have the send messages counters from openflowplugin). Please push one separate commit - where you remove these counters, so that we can track it easily in case the counters are needed in the future.

 

Regards,

Michal


From: Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
Sent: 17 May 2016 08:10
To: Michal Polkoráb; Chinmay.Mohanta
Cc: openflowjava-dev@...; Shuva Jyoti Kar; Ashutosh Bisht; Muthukumaran K
Subject: RE: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Michal,

 

From our ongoing effort to debug some of the performance related issues we find that it greatly simplifies the debugging process if error cases (for example like message drop) are reported explicitly rather than implicitly (as a derivation). Explicit error reporting provides  *** sensible & precise contextual*** information which will expedite the process of finding the root cause of the issue.

 

In line with this principle we are still strongly considering to implement this new counter.

 

Pleases comment?

 

Thanks and Regards,

Chinmay Mohanta

 

 

From: Michal Polkoráb [mailto:michal.polkorab@...]
Sent: Friday, May 13, 2016 3:37 PM
To: Chinmay.Mohanta
Cc: openflowjava-dev@...; Shuva Jyoti Kar; Chinmay Kumar Mohanta; Ashutosh Bisht; Muthukumaran K
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Chinmay,

 

your point makes sense. However, we should thoroughly​ consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.

 

Michal


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 12 May 2016 13:27
To: Michal Polkoráb
Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Michal,

 

Thanks for your reply.

 

Indeed the formula indicated by you gives the expected value !!

So it obviates the implementation of a new counter.

 

However following new thoughts emerge.

 

Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?

 

Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).

 

I think we should have counts only for the error scenarios resulting least influence on the performance.

 

BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. 

 

Thanks and Regards,

Chinmay @ ericsson

 

On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello Chinmay,

 

is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.

 

Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi all,

 

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

 

Count name : DS_DROPPED_PACKET_QFULL

Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

 

Implementation implications:

 

This new count will be implemented using existing counter module StatisticsCounters.

 

Please share your comments (if any ).

 

Thanks and Regards,

Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 

 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: New message count for Openflow Java in ODL master (Boron)

Michal Polkoráb <michal.polkorab@...>
 

Hi Chinmay,


in that case please go ahead with your changes. You can also remove the two positive counters mentioned before to further improve the performance (we will still have the send messages counters from openflowplugin). Please push one separate commit - where you remove these counters, so that we can track it easily in case the counters are needed in the future.


Regards,

Michal


From: Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
Sent: 17 May 2016 08:10
To: Michal Polkoráb; Chinmay.Mohanta
Cc: openflowjava-dev@...; Shuva Jyoti Kar; Ashutosh Bisht; Muthukumaran K
Subject: RE: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 

Hi Michal,

 

From our ongoing effort to debug some of the performance related issues we find that it greatly simplifies the debugging process if error cases (for example like message drop) are reported explicitly rather than implicitly (as a derivation). Explicit error reporting provides  *** sensible & precise contextual*** information which will expedite the process of finding the root cause of the issue.

 

In line with this principle we are still strongly considering to implement this new counter.

 

Pleases comment?

 

Thanks and Regards,

Chinmay Mohanta

 

 

From: Michal Polkoráb [mailto:michal.polkorab@...]
Sent: Friday, May 13, 2016 3:37 PM
To: Chinmay.Mohanta
Cc: openflowjava-dev@...; Shuva Jyoti Kar; Chinmay Kumar Mohanta; Ashutosh Bisht; Muthukumaran K
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Chinmay,

 

your point makes sense. However, we should thoroughly​ consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.

 

Michal


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 12 May 2016 13:27
To: Michal Polkoráb
Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Michal,

 

Thanks for your reply.

 

Indeed the formula indicated by you gives the expected value !!

So it obviates the implementation of a new counter.

 

However following new thoughts emerge.

 

Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?

 

Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).

 

I think we should have counts only for the error scenarios resulting least influence on the performance.

 

BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. 

 

Thanks and Regards,

Chinmay @ ericsson

 

On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello Chinmay,

 

is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.

 

Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi all,

 

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

 

Count name : DS_DROPPED_PACKET_QFULL

Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

 

Implementation implications:

 

This new count will be implemented using existing counter module StatisticsCounters.

 

Please share your comments (if any ).

 

Thanks and Regards,

Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 

 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: New message count for Openflow Java in ODL master (Boron)

Chinmay Kumar Mohanta <chinmay.kumar.mohanta@...>
 

Hi Michal,

 

From our ongoing effort to debug some of the performance related issues we find that it greatly simplifies the debugging process if error cases (for example like message drop) are reported explicitly rather than implicitly (as a derivation). Explicit error reporting provides  *** sensible & precise contextual*** information which will expedite the process of finding the root cause of the issue.

 

In line with this principle we are still strongly considering to implement this new counter.

 

Pleases comment?

 

Thanks and Regards,

Chinmay Mohanta

 

 

From: Michal Polkoráb [mailto:michal.polkorab@...]
Sent: Friday, May 13, 2016 3:37 PM
To: Chinmay.Mohanta
Cc: openflowjava-dev@...; Shuva Jyoti Kar; Chinmay Kumar Mohanta; Ashutosh Bisht; Muthukumaran K
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Chinmay,

 

your point makes sense. However, we should thoroughly​ consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.

 

Michal


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 12 May 2016 13:27
To: Michal Polkoráb
Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi Michal,

 

Thanks for your reply.

 

Indeed the formula indicated by you gives the expected value !!

So it obviates the implementation of a new counter.

 

However following new thoughts emerge.

 

Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?

 

Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).

 

I think we should have counts only for the error scenarios resulting least influence on the performance.

 

BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. 

 

Thanks and Regards,

Chinmay @ ericsson

 

On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello Chinmay,

 

is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.

 

Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)

 

Hi all,

 

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

 

Count name : DS_DROPPED_PACKET_QFULL

Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

 

Implementation implications:

 

This new count will be implemented using existing counter module StatisticsCounters.

 

Please share your comments (if any ).

 

Thanks and Regards,

Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 

 

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: New message count for Openflow Java in ODL master (Boron)

Michal Polkoráb <michal.polkorab@...>
 

Hi Chinmay,


you can turn the counters on / off by providing the <statistics> element in 45-openflowjava-stats.xml file (inside openflowjava-config module). If this element is present, counters will be enabled. If the tag is missing, counters won't be enabled.


Regards,

Michal


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 16 May 2016 08:11
To: Michal Polkoráb
Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi Michal and all,

In that case I think best would be to introduce the functionality that would allow to enable/disable (via JMX or Config subsys) the counter module on demand.

In this way we can have the message counts when we need it otherwise count collection can be turned off.

comment ?


Thanks and Regards,
Chinmay @ Ericsson

On Fri, May 13, 2016 at 3:37 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hi Chinmay,


your point makes sense. However, we should thoroughly​ consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.


Michal


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 12 May 2016 13:27
To: Michal Polkoráb
Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi Michal,

Thanks for your reply.

Indeed the formula indicated by you gives the expected value !!
So it obviates the implementation of a new counter.

However following new thoughts emerge.

Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?

Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).

I think we should have counts only for the error scenarios resulting least influence on the performance.

BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. 

Thanks and Regards,
Chinmay @ ericsson

On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello Chinmay,


is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESSDS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.


Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi all,

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

Count name : DS_DROPPED_PACKET_QFULL
Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

Implementation implications:

This new count will be implemented using existing counter module StatisticsCounters.

Please share your comments (if any ).

Thanks and Regards,
Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: New message count for Openflow Java in ODL master (Boron)

Chinmay.Mohanta <mohanta.chinmay@...>
 

Hi Michal and all,

In that case I think best would be to introduce the functionality that would allow to enable/disable (via JMX or Config subsys) the counter module on demand.

In this way we can have the message counts when we need it otherwise count collection can be turned off.

comment ?


Thanks and Regards,
Chinmay @ Ericsson

On Fri, May 13, 2016 at 3:37 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hi Chinmay,


your point makes sense. However, we should thoroughly​ consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.


Michal


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 12 May 2016 13:27
To: Michal Polkoráb
Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi Michal,

Thanks for your reply.

Indeed the formula indicated by you gives the expected value !!
So it obviates the implementation of a new counter.

However following new thoughts emerge.

Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?

Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).

I think we should have counts only for the error scenarios resulting least influence on the performance.

BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. 

Thanks and Regards,
Chinmay @ ericsson

On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello Chinmay,


is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESSDS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.


Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi all,

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

Count name : DS_DROPPED_PACKET_QFULL
Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

Implementation implications:

This new count will be implemented using existing counter module StatisticsCounters.

Please share your comments (if any ).

Thanks and Regards,
Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 



Re: New message count for Openflow Java in ODL master (Boron)

Michal Polkoráb <michal.polkorab@...>
 

Hi Chinmay,


your point makes sense. However, we should thoroughly​ consider removing these counters. These were introduced in the past to check if / where there are messages being lost between openflowplugin & openflowjava + to verify the backpressure mechanism. If we similar issue appears again, these counters might be handy.


Michal


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 12 May 2016 13:27
To: Michal Polkoráb
Cc: openflowjava-dev@...; shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: Re: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi Michal,

Thanks for your reply.

Indeed the formula indicated by you gives the expected value !!
So it obviates the implementation of a new counter.

However following new thoughts emerge.

Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?

Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).

I think we should have counts only for the error scenarios resulting least influence on the performance.

BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. 

Thanks and Regards,
Chinmay @ ericsson

On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello Chinmay,


is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESSDS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.


Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi all,

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

Count name : DS_DROPPED_PACKET_QFULL
Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

Implementation implications:

This new count will be implemented using existing counter module StatisticsCounters.

Please share your comments (if any ).

Thanks and Regards,
Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Anil Vishnoi
 



On Thu, May 12, 2016 at 6:53 AM, Alexis de Talhouët <adetalhouet@...> wrote:

On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote:

So, did the TWS on this topic actually happen? I think it didn’t
Correct it didn’t, last TWS focused on phased release and semantic versioning.
, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here:

1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have.
+1, absolutely.
​+1​
 


Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand.

2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it.
+1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella.
​+1​
 


3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful.
I’m not sure to get the question here so I will at careful at further discussion.

Thanks,
Alexis

--Colin


On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote:


On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote:
On 05/09/2016 07:13 PM, Anil Vishnoi wrote:
> ​ I think this is one of the reason as well, but the higher level goal
> was to use them as a controller wide ​model and that was the reason we
> added all these models in the controller projects.

Right, but that was not really how it got marketed :) In fact it was
recognized that they are OpenFlow specific when we were deciding whether
to move them.

So was the idea to essentially define an 'OpenDaylight forwarding model'?
Let me put it in this way-- this was the real intent, but the implementation was openflow influenced ​:)

I am not quite sure how PCEP would map onto the OFP models, as there
would have to be a way to communicate the fact that things like L2
matches simply make no sense (unless some new PCEP extensions get
defined and are supported by the device)...
​...and this is one of many reason we realize lets move it to openflowplugin project :)​
 

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?
​..that's probably one way to go about it ... but it's open for thoughts 

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?
​Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not 
really 
​version ​
agnostic. 
And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). 

Bye,
Robert




-- 
Thanks
Anil

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev




--
Thanks
Anil


Re: [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Abhijit Kumbhare
 

Yes - as Alex mentioned during the last meeting the topic was phased release & semantic versioning - but we could do it on the coming Monday.

About the last point - I think we should:

1. Not get rid of the existing abstracted OpenDaylight forwarding model in the near future - may be for a long time - as the existing OpenDaylight applications are written toward this forwarding model.
2. Over period add an additional optimized non-abstract OpenFlow forwarding model for select cases where the performance would be critical (example flow programming). Over time applications could migrate toward this forwarding model & then could be deprecated. 



On Thu, May 12, 2016 at 6:54 AM, Colin Dixon <colin@...> wrote:
The last question is basically, should we merge openflowjava and openflowplugin into one project? leave them apart? or pick a different splitting point?

That was basically the focus of the 3-5 mails before mine above.

--Colin


On Thu, May 12, 2016 at 9:53 AM, Alexis de Talhouët <adetalhouet@...> wrote:

On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote:

So, did the TWS on this topic actually happen? I think it didn’t
Correct it didn’t, last TWS focused on phased release and semantic versioning.
, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here:

1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have.
+1, absolutely.

Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand.

2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it.
+1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella.

3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful.
I’m not sure to get the question here so I will at careful at further discussion.

Thanks,
Alexis

--Colin


On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote:


On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote:
On 05/09/2016 07:13 PM, Anil Vishnoi wrote:
> ​ I think this is one of the reason as well, but the higher level goal
> was to use them as a controller wide ​model and that was the reason we
> added all these models in the controller projects.

Right, but that was not really how it got marketed :) In fact it was
recognized that they are OpenFlow specific when we were deciding whether
to move them.

So was the idea to essentially define an 'OpenDaylight forwarding model'?
Let me put it in this way-- this was the real intent, but the implementation was openflow influenced ​:)

I am not quite sure how PCEP would map onto the OFP models, as there
would have to be a way to communicate the fact that things like L2
matches simply make no sense (unless some new PCEP extensions get
defined and are supported by the device)...
​...and this is one of many reason we realize lets move it to openflowplugin project :)​
 

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?
​..that's probably one way to go about it ... but it's open for thoughts 

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?
​Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not 
really 
​version ​
agnostic. 
And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). 

Bye,
Robert




-- 
Thanks
Anil

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev



_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev



Re: [OpenDaylight Discuss] [opendaylight-dev] TWS on reorganizing the OpenFlow projects

Colin Dixon
 

And the need to have a new groupID means that downstream projects would be affected and have to change their dependency information in their pom files.

--Colin


On Thu, May 12, 2016 at 9:59 AM, Andrew Grimberg <agrimberg@...> wrote:
On 05/12/2016 06:43 AM, Colin Dixon wrote:
> So, did the TWS on this topic actually happen? I think it didn't, but it
> probably should in the near future. It sounds like there's two (or maybe
> three) orthogonal questions here:
>
> 1.) Should the tightly entwined OpenFlow projects be collocated under a
> single openflow project like we did with integration and releng? I'd say
> that's pretty clearly a yes, but we need to decide when and what impact
> it will have.
>
> Thanh and Andy, do you have any comments there? Also, I don't remember
> if we got to keep group-level isolation of artifact names after we do
> that, which would be important to understand.

I'll point out a couple of things with a restructure:

1) Build history might potentially be lost if the projects change their
final component name (which is unlikely). Just changing the logical
parentage shouldn't be an issue though we would have to lock access to
the repos during the transition.

2) We base the artifact namespacing upon the repo name. So, an example
of foo/bar/baz.git in Gerrit would have a namespace of
org.opendaylight.foo.bar.baz.* in Nexus.

3) With #2 in mind a reorg does mean that their merge jobs will fail
until they update their groupID to the newly designated groupID.

-Andy-

--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



Re: [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Andrew Grimberg <agrimberg@...>
 

On 05/12/2016 06:43 AM, Colin Dixon wrote:
So, did the TWS on this topic actually happen? I think it didn't, but it
probably should in the near future. It sounds like there's two (or maybe
three) orthogonal questions here:

1.) Should the tightly entwined OpenFlow projects be collocated under a
single openflow project like we did with integration and releng? I'd say
that's pretty clearly a yes, but we need to decide when and what impact
it will have.

Thanh and Andy, do you have any comments there? Also, I don't remember
if we got to keep group-level isolation of artifact names after we do
that, which would be important to understand.
I'll point out a couple of things with a restructure:

1) Build history might potentially be lost if the projects change their
final component name (which is unlikely). Just changing the logical
parentage shouldn't be an issue though we would have to lock access to
the repos during the transition.

2) We base the artifact namespacing upon the repo name. So, an example
of foo/bar/baz.git in Gerrit would have a namespace of
org.opendaylight.foo.bar.baz.* in Nexus.

3) With #2 in mind a reorg does mean that their merge jobs will fail
until they update their groupID to the newly designated groupID.

-Andy-

--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation


Re: [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Colin Dixon
 

The last question is basically, should we merge openflowjava and openflowplugin into one project? leave them apart? or pick a different splitting point?

That was basically the focus of the 3-5 mails before mine above.

--Colin


On Thu, May 12, 2016 at 9:53 AM, Alexis de Talhouët <adetalhouet@...> wrote:

On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote:

So, did the TWS on this topic actually happen? I think it didn’t
Correct it didn’t, last TWS focused on phased release and semantic versioning.
, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here:

1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have.
+1, absolutely.

Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand.

2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it.
+1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella.

3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful.
I’m not sure to get the question here so I will at careful at further discussion.

Thanks,
Alexis

--Colin


On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote:


On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote:
On 05/09/2016 07:13 PM, Anil Vishnoi wrote:
> ​ I think this is one of the reason as well, but the higher level goal
> was to use them as a controller wide ​model and that was the reason we
> added all these models in the controller projects.

Right, but that was not really how it got marketed :) In fact it was
recognized that they are OpenFlow specific when we were deciding whether
to move them.

So was the idea to essentially define an 'OpenDaylight forwarding model'?
Let me put it in this way-- this was the real intent, but the implementation was openflow influenced ​:)

I am not quite sure how PCEP would map onto the OFP models, as there
would have to be a way to communicate the fact that things like L2
matches simply make no sense (unless some new PCEP extensions get
defined and are supported by the device)...
​...and this is one of many reason we realize lets move it to openflowplugin project :)​
 

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?
​..that's probably one way to go about it ... but it's open for thoughts 

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?
​Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not 
really 
​version ​
agnostic. 
And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). 

Bye,
Robert




-- 
Thanks
Anil

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev



Re: [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Alexis de Talhouët <adetalhouet@...>
 


On May 12, 2016, at 9:43 AM, Colin Dixon <colin@...> wrote:

So, did the TWS on this topic actually happen? I think it didn’t
Correct it didn’t, last TWS focused on phased release and semantic versioning.
, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here:

1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have.
+1, absolutely.

Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand.

2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it.
+1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them under the same umbrella.

3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful.
I’m not sure to get the question here so I will at careful at further discussion.

Thanks,
Alexis

--Colin


On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote:


On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote:
On 05/09/2016 07:13 PM, Anil Vishnoi wrote:
> ​ I think this is one of the reason as well, but the higher level goal
> was to use them as a controller wide ​model and that was the reason we
> added all these models in the controller projects.

Right, but that was not really how it got marketed :) In fact it was
recognized that they are OpenFlow specific when we were deciding whether
to move them.

So was the idea to essentially define an 'OpenDaylight forwarding model'?
Let me put it in this way-- this was the real intent, but the implementation was openflow influenced ​:)

I am not quite sure how PCEP would map onto the OFP models, as there
would have to be a way to communicate the fact that things like L2
matches simply make no sense (unless some new PCEP extensions get
defined and are supported by the device)...
​...and this is one of many reason we realize lets move it to openflowplugin project :)​
 

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?
​..that's probably one way to go about it ... but it's open for thoughts 

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?
​Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not 
really 
​version ​
agnostic. 
And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). 

Bye,
Robert




-- 
Thanks
Anil

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev


Re: [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Colin Dixon
 

So, did the TWS on this topic actually happen? I think it didn't, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here:

1.) Should the tightly entwined OpenFlow projects be collocated under a single openflow project like we did with integration and releng? I'd say that's pretty clearly a yes, but we need to decide when and what impact it will have.

Thanh and Andy, do you have any comments there? Also, I don't remember if we got to keep group-level isolation of artifact names after we do that, which would be important to understand.

2.) Do we want to move related, but not-so-entwined projects into that too? These would be OF config and TTP for now. I'd argue yes, but I'm not going to fight a war for it.

3.) Do we want to keep the separation between the OpenDaylight forwarding model and OpenFlow plugin? This is more involved and I think could be punted forward, but my general take is that the division we actually wound up with was different than that and maybe less useful.

--Colin


On Mon, May 9, 2016 at 11:42 PM, Anil Vishnoi <vishnoianil@...> wrote:


On Mon, May 9, 2016 at 1:57 PM, Robert Varga <nite@...> wrote:
On 05/09/2016 07:13 PM, Anil Vishnoi wrote:
> ​ I think this is one of the reason as well, but the higher level goal
> was to use them as a controller wide ​model and that was the reason we
> added all these models in the controller projects.

Right, but that was not really how it got marketed :) In fact it was
recognized that they are OpenFlow specific when we were deciding whether
to move them.

So was the idea to essentially define an 'OpenDaylight forwarding model'?
Let me put it in this way-- this was the real intent, but the implementation was openflow influenced ​:)

I am not quite sure how PCEP would map onto the OFP models, as there
would have to be a way to communicate the fact that things like L2
matches simply make no sense (unless some new PCEP extensions get
defined and are supported by the device)...
​...and this is one of many reason we realize lets move it to openflowplugin project :)​
 

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?
​..that's probably one way to go about it ... but it's open for thoughts 

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?
​Although we tried to keep the existing openflowplugin model agnostic to openflow version, but current versions are not 
really
​version ​
agnostic. 
And in attempt to keep it version agnostic we ended up with writing lot of complex code to handle the scenario where user usage openflow 1.0 instructions to program the openflow 1.3 devices and vice versa. VLAN matching is one classic example of this issue. Given that ONF don't care about maintaining the backward compatibility of the openflow specs, i am not sure how easy it's going to be for us to maintain the sanity through version agnostic way :). 

Bye,
Robert




--
Thanks
Anil

_______________________________________________
dev mailing list
dev@...
https://lists.opendaylight.org/mailman/listinfo/dev



Re: New message count for Openflow Java in ODL master (Boron)

Chinmay.Mohanta <mohanta.chinmay@...>
 

Hi Michal,

Thanks for your reply.

Indeed the formula indicated by you gives the expected value !!
So it obviates the implementation of a new counter.

However following new thoughts emerge.

Do we really need the counts DS_ENTERED_OFJAVA and DS_ENCODE_SUCCESS ?

Maintaining these two counts (for every message) is costly in terms of performance (due to need for synchronization).

I think we should have counts only for the error scenarios resulting least influence on the performance.

BTW, my goal is to simplify the debugging process to find out whenever/wherever there is a message drop due to resource contention. Message drop count will provide an essential input to rationalize the provisioning of resources. 

Thanks and Regards,
Chinmay @ ericsson

On Wed, May 11, 2016 at 5:22 PM, Michal Polkoráb <michal.polkorab@...> wrote:

Hello Chinmay,


is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESSDS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.


Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi all,

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

Count name : DS_DROPPED_PACKET_QFULL
Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

Implementation implications:

This new count will be implemented using existing counter module StatisticsCounters.

Please share your comments (if any ).

Thanks and Regards,
Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 



Re: New message count for Openflow Java in ODL master (Boron)

Michal Polkoráb <michal.polkorab@...>
 

Hello Chinmay,


is it really needed to add such counter ? One can get this number by DS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESSDS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its meaning when OutboundQueueManager is used as the manager enqueues all messages and the message count is controlled byt rpcQuota in openflowplugin.


Regards,

Michal

 


From: Chinmay.Mohanta <mohanta.chinmay@...>
Sent: 10 May 2016 15:22
To: openflowjava-dev@...
Cc: shuva.jyoti.kar@...; chinmay.kumar.mohanta@...; ashutosh.bisht@...; muthukumaran.k@...
Subject: [openflowjava-dev] New message count for Openflow Java in ODL master (Boron)
 
Hi all,

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

Count name : DS_DROPPED_PACKET_QFULL
Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

Implementation implications:

This new count will be implemented using existing counter module StatisticsCounters.

Please share your comments (if any ).

Thanks and Regards,
Chinmay @ ericsson

MichalPolkoráb

Software Engineer


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 378 907 / michal.polkorab@...
reception: +421 2 206 65 114 / www.pantheon.sk

logo

 


Re: Hi, question about "flow"

Ryan Dietrich
 

So, to answer my own question, the message ends up going to Akka, hence the lack of seeing it in the traceback.  I knew Akka was in the mix after looking at various diagrams and seeing it all over the logs, but I wasn’t totally sure where the handoff was.

On the flip side, when it comes to tracing out calls to the southbound plugin I’m working on, I found that Akka was not in the mix, and instead it went to an LMAX Disruptor against a thread pool (dispatched by the NotificationPopListener/DOMNotificationRouter until eventually the magical BindingDOMNotiificationListenerAdapter does some weird looking reflection call to call to call whatever your plugin is doing).  Oh, and I was surprised to see disruptor in the mix, I haven’t seen anyone use that approach since my time in HFT.  You guys are serious about performance.

So, in case anyone gets this message in a google search, read this document:  https://github.com/opendaylight/docs/blob/master/manuals/developer-guide/src/main/asciidoc/openflowjava/odl-openflowjava-protocol-dev.adoc (it is really good, and explains the life cycle and flow of a southbound plugin, specifically the section called: TCP Channel Pipeline).

I’m still looking for a hook in my southbound plugin to receive “PacketInMessage” callbacks when they are received by the TCPHandler on 6653.  Today I’m going to randomly try assigning various elements to my yang configuration to see if the appropriate structure shows up in my auto-generated “Abstract${PROJECT}ImplModule.java” file.  Again, if anyone can give me a hint or a clue I’d appreciate it.

-Ryan Dietrich

On Apr 19, 2016, at 1:47 PM, Ryan Dietrich <ryan@...> wrote:

Thanks for the notes.  I’ll drop another line when I get it all figured out :)

On Apr 19, 2016, at 12:06 PM, Moiz Raja (moraja) <moraja@...> wrote:

If there were more operations done on that read write transaction then you should see more TransactionProxy logging. The presentation should have an example of transaction logging.

-Moiz

From: <openflowjava-dev-bounces@...> on behalf of Ryan Dietrich <ryan@...>
Date: Tuesday, April 19, 2016 at 10:48 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>
Subject: Re: [openflowjava-dev] Hi, question about "flow"

I know where the TransactionProxy “is” from a file location perspective.  It is in the controller repo, under md-sal.

I don’t understand from a processing perspective you get from TicketProcessor to the TransactionProxy. (I’m looking at the “translate” call in TicketProcessorFactoryImpl.  That looks like it is translating the response, back to a result set?)

Is there any documentation or videos that describe the path from the TCP packet in that steps you all the way through to MD-SAL making a query to the database?
I just want to know how a request is served by openflowplugin-java to MD-SAL / distributed-datastore.

Here are the logs I am referring to (I can find the logic pathway form TcpHandler all the way to TicketProcessorFactoryImpl, but after that the “trail” goes cold):

2016-04-18 14:40:31,403 | DEBUG | ntLoopGroup-11-1 | ConnectionAdapterImpl            | 177 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.7.0.Beryllium | ConsumeIntern msg on [id: 0x67c3f8a9, /10.20.116.148:7801 => /10.10.1.200:6653]
2016-04-18 14:40:31,403 | DEBUG | ntLoopGroup-11-1 | QueueKeeperHarvester             | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | pinging message harvester in starve status
2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | TicketProcessorFactoryImpl       | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | message received, type: MultipartReplyMessage
2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | TicketProcessorFactoryImpl       | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | translatorKey: 4 + org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.protocol.rev130731.MultipartReplyMessage
2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | MultipartReplyTranslator         | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | Received group statistics multipart reponse
2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | MultipartReplyTranslator         | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | Converted group statistics : org.opendaylight.yang.gen.v1.urn.opendaylight.group.statistics.rev131111.GroupStatisticsUpdatedBuilder@5cfbeda4
2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | TicketProcessorFactoryImpl       | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | message processing done (type: MultipartReplyMessage, ticket: 1371401748)
2016-04-18 14:40:31,407 | DEBUG | ds-oper-thread-0 | TransactionProxy                 | 164 - org.opendaylight.controller.sal-distributed-datastore - 1.3.0.Beryllium | New READ_WRITE Tx - member-1-chn-1-txn-2061-1461012031407




On Apr 19, 2016, at 11:15 AM, Moiz Raja (moraja) <moraja@...> wrote:

TransactionProxy is in the Distributed data store (aka Clustered data store). The code for that is in the controller project. Look for module sal-distritributed-datastore.

-Moiz

From: <openflowjava-dev-bounces@...> on behalf of Ryan Dietrich <ryan@...>
Date: Tuesday, April 19, 2016 at 10:04 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>
Subject: [openflowjava-dev] Hi, question about "flow"

Hi, I am just starting out with OpenDaylight and I feel like this:
https://img.buzzfeed.com/buzzfeed-static/static/2014-10/26/6/enhanced/webdr08/enhanced-14836-1414320930-8.jpg

I have a firm grip on the netty library in Java, so I decided to start with the TcpHandler class and work my way backwards until I found the linkage to what is making calls to the database.

I got lost at the “Tickets” area in the code.   I cannot figure out how you get to TransactionProxy (which I see in the karaf logs as the next “step” of execution before a response is returned), following the chain of events from 

TcpHandler
TcpChannelInitializer
DelegatingInboundHandler
ConectionAdapterImpl
OutboundQueueManager
ConnectionConductorImpl
QueueKeeper
QueueProcessorLightImpl
TicketProcessorHandlerImpl
???
???
TransactionProxy

I am trying to learn how to create a plugin of sorts for the south bound interface of Open Daylight, allowing me to choose whether MD-SAL references its own data store, or make calls externally to my systems.  Basically, I want to try and create an “aspect programming” concept that intercepts all GET requests going to MD-SAL, and allows me to make a decision on where to get the information (such as a REST request to a third party system).  I assume this is not the “norm”, after looking at the Toaster provider plugin example.  Am I barking up the wrong tree?  Can anyone help me fill in the blanks on how a request on how southbound requests are serviced?  Any and all information to help me get a footing in this system is much appreciated!

Also, I’d like to pay a compliment to the developers of this project.  I’ve worked on a lot of Java applications in my career, and this is some really well written (and tested!) code.

-Ryan Dietrich


_______________________________________________
openflowjava-dev mailing list
openflowjava-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev


New message count for Openflow Java in ODL master (Boron)

Chinmay.Mohanta <mohanta.chinmay@...>
 

Hi all,

To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count.

Count name : DS_DROPPED_PACKET_QFULL
Purpose : To count messages dropped because the queue present in ChannelOutboundQueue is full. This count will be helpful to mark the threshold downstream message processing capability of Openflow Java. Downsizing/upsizing resources surrounding this counter will decrease/increase downstream message processing capability.

Implementation implications:

This new count will be implemented using existing counter module StatisticsCounters.

Please share your comments (if any ).

Thanks and Regards,
Chinmay @ ericsson

181 - 200 of 861