z.archive.ttp-dev@lists.opendaylight.org | [opendaylight-dev] [OpenDaylight Discuss] TWS on reorganizing the OpenFlow projects

Home Messages Hashtags Subgroups

This group is locked. No changes can be made to the group while it is locked.

Date Date 1 - 9 of 9

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

Andrew Grimberg <agrimberg@...> #142 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 signature.asc signature.asc
Colin Dixon #139 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 toggle quoted message Show quoted text 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
Anil Vishnoi <vishnoianil@...> #138 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
Robert Varga <nite@...> #137 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 signature.asc signature.asc
Abhijit Kumbhare #136 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
Robert Varga <nite@...> #135 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 signature.asc signature.asc
Abhijit Kumbhare #134 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
Anil Vishnoi <vishnoianil@...> #133 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
Robert Varga <nite@...> #132 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 signature.asc signature.asc

1 - 9 of 9

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms