Open Stack

On Wed, Aug 6, 2014 at 1:52 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 08/06/2014 04:36 PM, Sumit Naiksatam wrote:
>>
>> 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];
>>
>> L36-L38
>> "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
>
>
> OK, cool. Then it seems to me that would be a perfect justification for
> having this code and API live outside of the Neutron tree, then?
>
> In other words, what benefit does having the GBP code in the Neutron
> codebase give us?
>

And for that I would again request that you look at the following
stated in the blueprint spec ;-):

L43-48
"This proposal suggests a model that allows application administrators to
express their networking requirements using group and policy
abstractions, with the specifics of policy enforcement and
implementation left to the underlying policy driver. 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."

L52-78 also spell out some of the details of these claims.


> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev