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 <loywo...@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 <pc2...@att.com> wrote: >> >> loy wolfe [mailto:loywo...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
