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

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

 

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

 

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

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

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

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

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