Open Stack

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 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