Open Stack

hi GBPer,

I couldn't have been at the IRC meeting for the time difference, are there any conclusion for this topic, or is it still open? 
I've tried to collect main concerns from previous posts (if something is lost or mistaken, just let me know):

Concern 1: GBP is too heavy to be merged into Neutron;
Concern 2: GBP should be on Neutron, but not in it, for it's only additional;
Concern 3: No value of some GBP resources compared with Neutron core;

Concern 4: GBP should be in Neutron,intercepting for consistency validation
Concern 5: GBP has extensions to expose better API interface;
Concert 6: GBP should be in Neutron for better performance

Is it an option to split the GBP into core and extension, to easily meet all those concerns? GBP core resource only has policy-template (with contracts in it), which is created clearly without binding to network/subnet; GBP extension can define it's own EP/EPG/L2P/L3P resource, to allow for a better and enhanced *application-centric* interface as has been claimed by someone but objected by others.

GBP core should be merged into Neutron as a optional service plugin,  and nova needs not any extension to interact with GBP, while policy-template must be associated with existing Neutron core resource. Now with this smallest lightweight plugin, Neutron expose atomic policy APIs without losing any concerns: interception could be enabled for policy validation,  other security backend is permitted instead of SG for performance optimization.

GBP extension shouldn't be merged into Neutron, its application-centric API can be mapped to atomic Neutron resources API via standard Restful python-client, just as what HEAT work with nova/neutron/cinder. This extension could be implemented as a standalone component, or as an integral part of HEAT or Congress.

________________________________________
From: Sumit Naiksatam [sumitnaiksatam at gmail.com]
Sent: Wednesday, August 13, 2014 12:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the      way forward

Per the blueprint spec [1], what has been proposed are optional
extensions which complement the existing Neutron core resources'
model:

"
The main advantage of the extensions described in this blueprint is
that they allow for an application-centric interface to Neutron that
complements the existing network-centric interface.
"

It has been pointed out earlier in this thread that this is not a
replacement for the current Neutron core resources/API.

[1] https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm

On Tue, Aug 12, 2014 at 1:22 AM, loy wolfe <loywolfe at gmail.com> wrote:
> Hi Paul,
>
> Below are some other useful GBP reference pages:
> https://wiki.opendaylight.org/view/Project_Proposals:Group_Based_Policy_Plugin
> http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps13004/ps13460/white-paper-c11-729906_ns1261_Networking_Solutions_White_Paper.html
>
> I think the root cause of this long argument, is that GBP core model was not
> designed native for Neutron, and they are introduced into Neutron so
> radically, without careful tailoring and adaption. Maybe the GBP team also
> don't want to do so, their intention is to maintain a unified model across
> all kinds of platform including Neutron, Opendaylight, ACI/Opflex, etc.
>
> However, redundancy and duplication exists between EP/EPG/BD/RD and
> Port/Network/Subnet. So mapping is used between these objects, and I think
> this is why so many voice to request moving GBP out and on top of Neutron.
>
> Will GBP simply be an *addition*? It absolutely COULD be, but objectively
> speaking, it's core model also allow it to BE-ABLE-TO take over Neutron core
> resource (see the wiki above). GBP mapping spec suggested a nova -nic
> extension to handle EP/EPG resource directly, thus all original Neutron core
> resource can be shadowed away from user interface: GBP became the new
> openstack network API :-) However no one can say depreciate Neutron core
> here and now, but shall we leave Neutron core just as *traditional/legacy*?
>
> Personally I prefer not to throw NW-Policy out of Neutron, but at the
> perquisite that its core model should be reviewed and tailored. A new
> lightweight model carefully designed native for Neutron is needed, but not
> directly copying a whole bunch of monolithic core resource from existing
> other system.
>
> Here is the very basic suggestion: because core value of GBP is policy
> template with contracts , throw away EP/EPG/L2P/L3P model while not just
> renaming them again and again. APPLY policy template to existing Neutron
> core resource, but not reinvent similar concept in GBP and then do the
> mapping.
>
>
> On Mon, Aug 11, 2014 at 9:12 PM, CARVER, PAUL <pc2929 at att.com> wrote:
>>
>> loy wolfe [mailto:loywolfe at gmail.com] wrote:
>>
>>
>>
>> >Then since Network/Subnet/Port will never be treated just as LEGACY
>>
>> >COMPATIBLE role, there is no need to extend Nova-Neutron interface to
>>
>> >follow the GBP resource. Anyway, one of optional service plugins inside
>>
>> >Neutron shouldn't has any impact on Nova side.
>>
>>
>>
>> This gets to the root of why I was getting confused about Jay and others
>>
>> having Nova related concerns. I was/am assuming that GBP is simply an
>>
>> *additional* mechanism for manipulating Neutron, not a deprecation of any
>>
>> part of the existing Neutron API. I think Jay's concern and the reason
>>
>> why he keeps mentioning Nova as the biggest and most important consumer
>>
>> of Neutron's API stems from an assumption that Nova would need to change
>>
>> to use the GBP API.
>>
>>
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev