Open Stack

On 08/06/2014 04:51 PM, Prasad Vellanki wrote:
> Jay
> Doesnt the current plugin model in neutron work the way you are saying.
> We have a a core set of APIs that there is a reference model for and
> individual vendors have substituted plugins that enhance and sometimes
> replace networking component. GBP in that respect does not change. There
> is a reference implementation in neutron for declarative model in
> neutron and vendors can substitute their implementation to enhance what
> is in reference.
>
> But what you need to understand is the declarative model that it
> provides which Ryan has elaborated which current neutron does not provide.

Why can't it live outside of the Neutron tree?

-jay

> On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes <jaypipes at gmail.com
> <mailto: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
>         <mailto: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
>     <http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain>
>
>
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>