Hi, I think that moving the VPP renderer outside of GBP will be just adding work for us and as you said It will break our concept of universal core that cooperates with renderers for different devices. We also have some RPC that can be used to create configuration for VPP devices. Any project can benefit from them and even they can be extended in the future. I have one question too. Currently GBP uses VBD to manage bridgedomains across VPP nodes. It also uses VBD to store yang models that we need to communicate with HC. Do you want the models to be moved to VPP project too. Otherwise it can create problems and conflicts between models in VBD and other projects that maintain their own copy of the same models. And as Vlado suggested we will need to maintain GBP, VBD and also the new VPP project which complicates things for us.
Michal From: [email protected] [mailto:[email protected]] On Behalf Of Vladimir Lavor -X (vlavor - PANTHEON TECHNOLOGIES at Cisco) Sent: Thursday, June 22, 2017 3:22 PM To: Ed Warnicke <[email protected]>; Yang, Yi Y <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [groupbasedpolicy-dev] [Project-proposals] A new project proposal vpp Forwarded to the official thread: ---------------------------------------- Hello Yi Yang, Brady, Sam, I went through your project proposal<https://wiki.opendaylight.org/view/Project_Proposals:Vpp> for new Vpp project and I want to ask you several questions. If I understand it correctly, you want to use current GBP Vpp renderer/classifier code into your new project. We spent several months of work on in so I don’t like the idea to move it away, but the main reason is that it would somehow break the main GBP concept. Current GBP implementation consists of two parts; the GBP core which creates a generic configuration from any northbound data provided and several renderers (including vpp) which “renders” the configuration to end devices. So my first question would be, what the Vpp project should actually do? From your proposal, it’s not clear how you are intending to configure a vpp device. Are you going to use netconf + honeycomb? Because that’s the same approach GBP is currently using. Then what about models? I guess GBP would need to share models which are not a part of standard api (generic configuration, etc.) or even create a new ones. It would be just another dependency for the GBP because we are using netconf in other renderers anyway. You have written that this new project will benefit all projects with vpp support. Unfortunately I have to ask you what are the benefits for GBP because I can’t see any. To cut the vpp renderer out and preserve compatibility within GBP + with an external vpp renderer is not an easy task and it’d definitely delay the development. Who will maintain the new project? The current GPB development it primary on vpp renderer, so with Honeycomb/VBD (controller app for bridge domains) it would be three projects to work with. So as a GBP PTL I really can’t support this proposal in current form. I don’t think there is something that can be achieved in proposed Vpp project and not in GBP and I think there are no benefits for us. However you are more than welcome to create your own fork from GBP and change whatever you like if it would be good enough for you, but pull the code out of GBP does not make sense to me. I also want to ask Michal Cmarada and Tomas Cechvala, the most active committers to vpp renderer, for their opinion. Guys if you have different point of view or have something to add, please do so. With best regards, Vlado From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ed Warnicke Sent: Thursday, June 22, 2017 3:07 PM To: Yang, Yi Y <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [groupbasedpolicy-dev] [Project-proposals] A new project proposal vpp Looping in GBP, SFC, and netvirt, as they are all mentioned in the proposal. Ed On Tue, Jun 20, 2017 at 4:37 AM, Yang, Yi Y <[email protected]<mailto:[email protected]>> wrote: Ed, I read vbd source code, what it does isn’t so much. But honeycomb isn’t ODL project, it isn’t in ODL integration release, as Abhijt said, vbd seems not to have active development activity, so I don’t think it is a good way to new a subproject under honeycomb/. I know some ideas in vbd are good, we can borrow some code in vbd to implement similar things in this newly-proposed project. Again, the goal is to avoid unnecessary duplicate effort, maybe you has different thoughts if you consider it from sfc view angle. From: Ed Warnicke [mailto:[email protected]<mailto:[email protected]>] Sent: Tuesday, June 20, 2017 5:24 AM To: Yang, Yi Y <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [Project-proposals] A new project proposal vpp Yi, One thought that occurs to me is that VBD is actually honeycomb/vbd. We may want to consider doing something under the honeycomb/* tree at ODL, especially since we are really talking about mounting and managing Honeycomb Agents. Those agents can certainly manage VPP, but they could also manage other things as well. In the case of honeycomb/vdb the naming was around virtual bridge domain (VBD)... basically naming it after the global cross node model being translated to the particular per-node models being mounted by netconf. It might be useful to start thinking in that direction. What is the global cross node model we are wanting to map to the models provided by Honeycomb? Ed On Sun, Jun 18, 2017 at 6:32 PM, Yang, Yi Y <[email protected]<mailto:[email protected]>> wrote: Ed, no problem, can you propose a better name? From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ed Warnicke Sent: Saturday, June 17, 2017 1:34 AM To: [email protected]<mailto:[email protected]> Subject: Re: [Project-proposals] A new project proposal vpp With my fd.io<http://fd.io> TSC chair hat on, I would like to formally request that this project *not* be named 'vpp' due to potential for confusion with the fd.io<http://fd.io> vpp project. Ed >On 16/06/17 03:56, Yang, Yi Y wrote: >> Hi, TSC members >> >> >> >> I’d like to propose a new project vpp >> https://wiki.opendaylight.org/view/Project_Proposals:Vpp, our goal is to >> avoid duplicate efforts for GBP, NetVirt and SFC vpp integration as well >> as fix multiple applications coexistence for VPP, I send this out per >> https://wiki.opendaylight.org/view/Simultaneous_Release:Nitrogen_Release_Plan#Schedule >> in order that we can incubate it as a formal project in Nitrogen release >> cycle or Oxygen, please schedule review process in next TSC meeting, >> thank you in advance. > > I would suggest a different name, as it can end up being very confusing > to talk about components when multiple projects have the same name... > > Regards, > Robert
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
