[groupbasedpolicy-dev] A new project proposal vpp
|
Vladimir Lavor -X (vlavor - PANTHEON TECHNOLOGIES@Cisco) <vlavor@...>
Forwarded to the official thread: ----------------------------------------
Hello Yi Yang, Brady, Sam,
I went through your project proposal 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: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...]
On Behalf Of Ed Warnicke
Sent: Thursday, June 22, 2017 3:07 PM To: Yang, Yi Y <yi.y.yang@...> Cc: netvirt-dev@...; project-proposals@...; sfc-dev@...; groupbasedpolicy-dev@... 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 <yi.y.yang@...> wrote:
|
|
|
|
Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES@Cisco) <mcmarada@...>
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: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...]
On Behalf Of Vladimir Lavor -X (vlavor - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, June 22, 2017 3:22 PM To: Ed Warnicke <hagbard@...>; Yang, Yi Y <yi.y.yang@...> Cc: netvirt-dev@...; project-proposals@...; sfc-dev@...; groupbasedpolicy-dev@... 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 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:
groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...]
On Behalf Of Ed Warnicke
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 <yi.y.yang@...> wrote:
|
|
|