[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

loy wolfe loywolfe at gmail.com
Mon Aug 11 08:28:58 UTC 2014

Hi Sumit,

First I want to say I'm not opposed to GBP itself, but has many confusion
about it's core resource model and how it will integrate with neutron core.

Do you mean for whatever GBP backend configured in any future Neutron
deployment, so long as they are in tree, then ML2 core plugin shall always
be there to expose the Neutron core resource: Network/Subnet/Port?

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.

If we agree on this point, core model of GBP should be reviewed, but not
just focus on naming convention whether it should be called EP or policy
target, then leaving some words here to emphasize GBP is only
complementary. In fact, EP/EPG/BD/RD has been designed to be ABLE TO
REPLACE Neutron core resource, with mapping as the first step to keep

In fact, if Neutron core source shall never to be swapped out, GBP core
object could be greatly simplified, because mapping already means
redundancy :-) Only policy-group is meaningful, behind which are very
important policy concept: consumer/producer contracts. After PG is defined,
it should be directly applied to existing Neutron core resource, but not
create similar concept of EP/L2P/L3P, then mapping to them. Mapping is
redundant, and I can understand it's necessity only if someday those
neutron core resource are planned to be swapped out.

Simple conclusion: if GBP is just an optional complementary, then after
defining policy template, directly APPLYING, but not create similar
redundant resource and then MAPPING it to existing neutron core resource.

On Sat, Aug 9, 2014 at 3:35 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 08/08/2014 12:29 PM, Sumit Naiksatam wrote:
>> Hi Jay, To extend Ivar's response here, the core resources and core
>> plugin configuration does not change with the addition of these
>> extensions. The mechanism to implement the GBP extensions is via a
>> service plugin. So even in a deployment where a GBP service plugin is
>> deployed with a driver which interfaces with a backend that perhaps
>> directly understands some of the GBP constructs, that system would
>> still need to have a core plugin configured that honors Neutron's core
>> resources. Hence my earlier comment that GBP extensions are
>> complementary to the existing core resources (in much the same way as
>> the existing extensions in Neutron).
> OK, thanks Sumit. That clearly explains things for me.
> Best,
> -jay
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140811/2da292a2/attachment.html>

More information about the OpenStack-dev mailing list