Date   

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

Anil Vishnoi
 



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


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

Robert Varga <nite@...>
 

On 05/09/2016 11:20 PM, Abhijit Kumbhare wrote:

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?

Abhijit>> I think we need to think through this a bit. (On a different
note since I saw the mention about the topology model - I sent the
following email about inventory model to topology model :
https://lists.opendaylight.org/pipermail/discuss/2016-May/006460.html )
Thanks for the pointer, I missed both that TWS and the thread. I will
follow up on it.



Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?


Abhijit>> Not sure what exactly you mean by some higher-level project -
do you mean OpenFlow Plugin?
I do not believe OFP should be the place -- it is technology specific,
after all.

NETCONF provides this naturally via mount point capabilities, I am not
sure which project provides an equivalent abstraction which works for
OpenFlow...

Bye,
Robert


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

Abhijit Kumbhare
 

Inline.

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

Abhijit>> If I remember right the key idea then was a model for "Flow Capable Devices" - via any protocol capable of providing flow like semantics to the flow capable devices. Of course - it never went that way as in OpenDaylight I believe the only flow capable protocol we have is OpenFlow.   


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)...
Abhijit>> Yes - will not make sense for devices/protocols which are not flow capable.
 

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?
Abhijit>> I think we need to think through this a bit. (On a different note since I saw the mention about the topology model - I sent the following email about inventory model to topology model : https://lists.opendaylight.org/pipermail/discuss/2016-May/006460.html )

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?

Abhijit>> Not sure what exactly you mean by some higher-level project - do you mean OpenFlow Plugin?

 

Bye,
Robert



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

Robert Varga <nite@...>
 

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

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

On a related note: does this mean that the OFJ models will be hooked
onto the topology model?

Would that imply that version-agnostic applications should rather be
using APIs defined by some higher-level project?

Bye,
Robert


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

Abhijit Kumbhare
 

In-line.

On Mon, May 9, 2016 at 10:13 AM, Anil Vishnoi <vishnoianil@...> wrote:


On Mon, May 9, 2016 at 9:17 AM, Robert Varga <nite@...> wrote:
On 05/09/2016 05:44 PM, Abhijit Kumbhare wrote:
> I added a slide for the impact to the OpenFlow consumers (downstream
> projects) as well as some clarifications in the reorganization slide
> that we should keep the backward compatibility. Also added disclaimers
> that this is not in the present - but in the future.
>
> Also made it a google slide format for easier viewing/sharing:
>
> https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit?usp=sharing

I would like to clarify slide 5. The original intent between the two
models worlds was *not* support for multiple SB protocols, but rather
multiple versions of OpenFlow itself (1.0 and 1.3). Therefore the 'upper
layer' models were supposed to be version-agnostic and the OFP would
perform translation to the appropriate version-specific (OFJ) model.
​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. 
That's my recollection as well - both the points (if it was only 1.0 & 1.3 the models would have been in the OpenFlow plugin right from the beginning, not in the controller first and then moved to OpenFlow plugin). I will add this second point regarding the 1.0 & 1.3 abstraction to the slide. 


Hence the idea was that the applications could transition between 1.0
and 1.3 devices without being modified. It may well be that this dream
has failed, but that is really what needs to be called out.
​Agree, I think Ed did try to simplify these models after we moved these model of openflowplugin, but that was not an easy job, probably that's the reason he gave up on it :).

Bye,
Robert




--
Thanks
Anil


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

Anil Vishnoi
 



On Mon, May 9, 2016 at 9:17 AM, Robert Varga <nite@...> wrote:
On 05/09/2016 05:44 PM, Abhijit Kumbhare wrote:
> I added a slide for the impact to the OpenFlow consumers (downstream
> projects) as well as some clarifications in the reorganization slide
> that we should keep the backward compatibility. Also added disclaimers
> that this is not in the present - but in the future.
>
> Also made it a google slide format for easier viewing/sharing:
>
> https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit?usp=sharing

I would like to clarify slide 5. The original intent between the two
models worlds was *not* support for multiple SB protocols, but rather
multiple versions of OpenFlow itself (1.0 and 1.3). Therefore the 'upper
layer' models were supposed to be version-agnostic and the OFP would
perform translation to the appropriate version-specific (OFJ) model.
​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. 

Hence the idea was that the applications could transition between 1.0
and 1.3 devices without being modified. It may well be that this dream
has failed, but that is really what needs to be called out.
​Agree, I think Ed did try to simplify these models after we moved these model of openflowplugin, but that was not an easy job, probably that's the reason he gave up on it :).

Bye,
Robert




--
Thanks
Anil


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

Robert Varga <nite@...>
 

On 05/09/2016 05:44 PM, Abhijit Kumbhare wrote:
I added a slide for the impact to the OpenFlow consumers (downstream
projects) as well as some clarifications in the reorganization slide
that we should keep the backward compatibility. Also added disclaimers
that this is not in the present - but in the future.

Also made it a google slide format for easier viewing/sharing:

https://docs.google.com/presentation/d/1J1ddSWCGXhbz94uNMM8xzO_ssrry3OebV7pgQWKDkrs/edit?usp=sharing
I would like to clarify slide 5. The original intent between the two
models worlds was *not* support for multiple SB protocols, but rather
multiple versions of OpenFlow itself (1.0 and 1.3). Therefore the 'upper
layer' models were supposed to be version-agnostic and the OFP would
perform translation to the appropriate version-specific (OFJ) model.

Hence the idea was that the applications could transition between 1.0
and 1.3 devices without being modified. It may well be that this dream
has failed, but that is really what needs to be called out.

Bye,
Robert


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

Abhijit Kumbhare
 

I added a slide for the impact to the OpenFlow consumers (downstream projects) as well as some clarifications in the reorganization slide that we should keep the backward compatibility. Also added disclaimers that this is not in the present - but in the future.

Also made it a google slide format for easier viewing/sharing:




On Sun, May 8, 2016 at 11:16 PM, Anil Vishnoi <vishnoianil@...> wrote:
Hi Abhijit,

It's would be helpful to add the impact on downstream project because of individual work items. Some of these work items are going to significantly impact the downstream project and this is one of the main criteria in decision making whether it make sense to go that direction or not :). 

On Fri, May 6, 2016 at 8:57 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Hi folks,

I put up a strawman proposal with the help of Anil, Muthu and Shuva. This can serve as a starting point of discussion - here it is attached. I also took the liberty of briefly mentioning OpenFlow 1.5 to gauge community interest & solicit volunteers for Carbon

Abhijit

On Thu, May 5, 2016 at 9:46 AM, Colin Dixon <colin@...> wrote:
During recent TSC meetings, we noticed that we have at least 6 OpenFlow-related projects:
* openflowplugin
* openflowjava
* of-config
* ofextensions/circuitsw
* ofextensions/epc
* ttp

It might make sense to reorganize them with some merging and maybe all of them being located under a common openflow/ root. It would be good to talk this through during a TWS in the future. Does this make sense to people? When works? This Monday (5/9)? A later date?

Thanks,
--Colin



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




--
Thanks
Anil


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

Anil Vishnoi
 

Hi Abhijit,

It's would be helpful to add the impact on downstream project because of individual work items. Some of these work items are going to significantly impact the downstream project and this is one of the main criteria in decision making whether it make sense to go that direction or not :). 

On Fri, May 6, 2016 at 8:57 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:
Hi folks,

I put up a strawman proposal with the help of Anil, Muthu and Shuva. This can serve as a starting point of discussion - here it is attached. I also took the liberty of briefly mentioning OpenFlow 1.5 to gauge community interest & solicit volunteers for Carbon

Abhijit

On Thu, May 5, 2016 at 9:46 AM, Colin Dixon <colin@...> wrote:
During recent TSC meetings, we noticed that we have at least 6 OpenFlow-related projects:
* openflowplugin
* openflowjava
* of-config
* ofextensions/circuitsw
* ofextensions/epc
* ttp

It might make sense to reorganize them with some merging and maybe all of them being located under a common openflow/ root. It would be good to talk this through during a TWS in the future. Does this make sense to people? When works? This Monday (5/9)? A later date?

Thanks,
--Colin



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




--
Thanks
Anil


Re: TWS on reorganizing the OpenFlow projects

Abhijit Kumbhare
 

Hi folks,

I put up a strawman proposal with the help of Anil, Muthu and Shuva. This can serve as a starting point of discussion - here it is attached. I also took the liberty of briefly mentioning OpenFlow 1.5 to gauge community interest & solicit volunteers for Carbon

Abhijit

On Thu, May 5, 2016 at 9:46 AM, Colin Dixon <colin@...> wrote:
During recent TSC meetings, we noticed that we have at least 6 OpenFlow-related projects:
* openflowplugin
* openflowjava
* of-config
* ofextensions/circuitsw
* ofextensions/epc
* ttp

It might make sense to reorganize them with some merging and maybe all of them being located under a common openflow/ root. It would be good to talk this through during a TWS in the future. Does this make sense to people? When works? This Monday (5/9)? A later date?

Thanks,
--Colin



Re: [ttp-dev] TWS on reorganizing the OpenFlow projects

Curt Beckmann <beckmann@...>
 

Monday can work for me if it is early Pacific time…  But I also trust you (Colin) to represent TTP if the meeting ends up later.

 

Curt

 

From: ttp-dev-bounces@... [mailto:ttp-dev-bounces@...] On Behalf Of Colin Dixon
Sent: Thursday, May 05, 2016 6:46 PM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco) <rovarga@...>; Abhijit Kumbhare <abhijitkoss@...>
Cc: <discuss@...> <discuss@...>; epc-dev@...; circuitsw-dev@...; of-config-dev@...; openflowplugin-dev@... <dev@...>; ttp-dev@...; openflowjava-dev@...
Subject: [ttp-dev] TWS on reorganizing the OpenFlow projects

 

During recent TSC meetings, we noticed that we have at least 6 OpenFlow-related projects:

* openflowplugin

* openflowjava

* of-config

* ofextensions/circuitsw

* ofextensions/epc

* ttp

It might make sense to reorganize them with some merging and maybe all of them being located under a common openflow/ root. It would be good to talk this through during a TWS in the future. Does this make sense to people? When works? This Monday (5/9)? A later date?

Thanks,

--Colin


NetIDE project dependency

Leckey, Alexander J <alexander.j.leckey@...>
 

Hi all,

 

The NetIDE project informs you that it is dependent on the following projects:

 

-          YANG Tools

-          OpenflowPlugin

-          OpenflowJava

-          MDSAL

 

Please acknowledge this dependency to support our M2 status update.

 

Thanks,

Alec Leckey

 

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.


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

Aneesha
 

Monday works for me Colin.

 

Thanks,

Aneesha

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Colin Dixon
Sent: Thursday, May 05, 2016 9:46 AM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Abhijit Kumbhare
Cc: <discuss@...>; epc-dev@...; circuitsw-dev@...; of-config-dev@...; openflowplugin-dev@...; ttp-dev@...; openflowjava-dev@...
Subject: [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

 

During recent TSC meetings, we noticed that we have at least 6 OpenFlow-related projects:

* openflowplugin

* openflowjava

* of-config

* ofextensions/circuitsw

* ofextensions/epc

* ttp

It might make sense to reorganize them with some merging and maybe all of them being located under a common openflow/ root. It would be good to talk this through during a TWS in the future. Does this make sense to people? When works? This Monday (5/9)? A later date?

Thanks,

--Colin


TWS on reorganizing the OpenFlow projects

Colin Dixon
 

During recent TSC meetings, we noticed that we have at least 6 OpenFlow-related projects:
* openflowplugin
* openflowjava
* of-config
* ofextensions/circuitsw
* ofextensions/epc
* ttp

It might make sense to reorganize them with some merging and maybe all of them being located under a common openflow/ root. It would be good to talk this through during a TWS in the future. Does this make sense to people? When works? This Monday (5/9)? A later date?

Thanks,
--Colin


Re: Hi, question about "flow"

Ryan Dietrich
 

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



Re: Hi, question about "flow"

Moiz Raja
 

See this - https://wiki.opendaylight.org/images/2/2d/MD-SAL_Clustering_Internals.pptx and https://www.youtube.com/watch?v=A9wAAbvliR0

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


Re: Hi, question about "flow"

Ryan Dietrich
 

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


Re: Hi, question about "flow"

Moiz Raja
 

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


Hi, question about "flow"

Ryan Dietrich
 

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


Re: Openflowjava project lead election

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

​Thank you for your votes.


Michal


From: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco) <mirehak@...>
Sent: 15 March 2016 10:00
To: Daniel Bartoš; Michal Polkoráb; openflowjava-dev
Subject: Re: Openflowjava project lead election
 

+1 for Michal Polkorab as project lead



Regards,

Michal




From: Daniel Bartoš <daniel.bartos@...>
Sent: Tuesday, March 15, 2016 09:57
To: Michal Polkoráb; openflowjava-dev
Cc: Michal Rehak -X (mirehak - PANTHEON TECHNOLOGIES at Cisco)
Subject: RE: Openflowjava project lead election
 

+1 for Michal being project lead

 

Thanks,

Daniel

 

From: Michal Polkoráb
Sent: Tuesday, March 15, 2016 09:44
To: openflowjava-dev <openflowjava-dev@...>
Cc: mirehak@...; Daniel Bartoš <daniel.bartos@...>
Subject: Openflowjava project lead election

 

Hello openflowjava committers,

 

as we started new release cycle, we have to elect new project lead. I would like to nominate myself for this role. Please vote +1, 0, -1 or nominate yourself.

 

Regards,

Michal 

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

 

DanielBartoš

Sales Manager


Sídlo Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R&D centrum 
Janka Kráľa 9 /  974 01 Banská Bystrica Slovakia
+421 918 620 503 / daniel.bartos@...
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

 

201 - 220 of 861