On 08/06/2014 04:51 PM, Prasad Vellanki wrote:
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?


On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@gmail.com>> wrote:

    On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:

        On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak...@gmail.com
        <mailto:blak...@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
            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

    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.



    OpenStack-dev mailing list

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to