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

Sumit Naiksatam sumitnaiksatam at gmail.com
Wed Aug 6 20:36:26 UTC 2014

On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak111 at gmail.com> wrote:
>>>> I believe the referential security group rules solve this problem
>>>> (unless
>>>> I'm not understanding):
>>> I think the disconnect is that you are comparing the way to current
>>> mapping
>>> driver implements things for the reference implementation with the
>>> existing
>>> APIs. Under this light, it's not going to look like there is a point to
>>> this
>>> code being in Neutron since, as you said, the abstraction could happen at
>>> a
>>> client. However, this changes once new mapping drivers can be added that
>>> implement things differently.
>>> Let's take the security groups example. Using the security groups API
>>> directly is imperative ("put a firewall rule on this port that blocks
>>> this
>>> IP") compared to a higher level declarative abstraction ("make sure these
>>> two endpoints cannot communicate"). With the former, the ports must
>>> support
>>> security groups and there is nowhere except for the firewall rules on
>>> that
>>> port to implement it without violating the user's expectation. With the
>>> latter, a mapping driver could determine that communication between these
>>> two hosts can be prevented by using an ACL on a router or a switch, which
>>> doesn't violate the user's intent and buys a performance improvement and
>>> works with ports that don't support security groups.
>>> Group based policy is trying to move the requests into the declarative
>>> abstraction so optimizations like the one above can be made.
>> Kevin, you have captured the GBP value prop and difference very
>> succinctly. The major difference is in the declarative (GBP) versus
>> imperative (current) style of programming.
>> This has been stated very clearly and explicitly in the blueprint
>> spec. If one does not appreciate the difference or advantage of one
>> over the other, then this discussion is pointless.
> "One" does appreciate the value of having porcelain APIs overlay a plumbing
> API. This discussion was about the proper way and place to introduce such
> functionality.
> However, it seems to me that the end-goal of the GBP effort is *actually* to
> provide a higher-layer API to Neutron that would essentially enable
> proprietary vendors to entirely swap out all of Neutron core for a new set
> of drivers that spoke proprietary device APIs.
> If this is the end-goal, it should be stated more clearly, IMO.

The goal and design intent is unambiguously stated in the spec [1];

"The policy framework described in this blueprint complements the current
Neutron model with the notion of policies that can be applied between
groups of endpoints."

Note the choice of words - "complements". The implementation also has
been faithful to this intent.

I am not sure why you would draw the conclusion that you did.

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

> The classic plumbing versus porcelain API conversation [1] is a good one,
> and one worth having in the context of Neutron.
> It's almost like some Neutron contributor folks are saying "let's add a
> porcelain API so we can ditch all the existing plumbing APIs and replace
> with our own stuff". And that's not what the point of plumbing vs. porcelain
> is.
> -jay
> [1] http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list