Open Stack

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
>