On 09/09/2014 06:57 PM, Kevin Benton wrote:
Hi Jay,

The main component that won't work without direct integration is
enforcing policy on calls directly to Neutron and calls between the
plugins inside of Neutron. However, that's only one component of GBP.
All of the declarative abstractions, rendering of policy, etc can be
experimented with here in the stackforge project until the incubator is
figured out.

OK, thanks for the explanation Kevin, that helps!

Best,
-jay

On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes <jaypi...@gmail.com
<mailto:jaypi...@gmail.com>> wrote:

    On 09/04/2014 12:07 AM, Sumit Naiksatam wrote:

        Hi,

        There's been a lot of lively discussion on GBP a few weeks back
        and we
        wanted to drive forward the discussion on this a bit more. As you
        might imagine, we're excited to move this forward so more people can
        try it out.  Here are the options:

        * Neutron feature branch: This presumably allows the GBP feature
        to be
        developed independently, and will perhaps help in faster iterations.
        There does seem to be a significant packaging issue [1] with this
        approach that hasn’t been completely addressed.

        * Neutron-incubator: This allows a path to graduate into
        Neutron, and
        will be managed by the Neutron core team. That said, the proposal is
        under discussion and there are still some open questions [2].

        * Stackforge: This allows the GBP team to make rapid and iterative
        progress, while still leveraging the OpenStack infra. It also
        provides
        option of immediately exposing the existing implementation to early
        adopters.

        Each of the above options does not preclude moving to the other
        at a later time.

        Which option do people think is more preferable?

        (We could also discuss this in the weekly GBP IRC meeting on
        Thursday:
        https://wiki.openstack.org/__wiki/Meetings/Neutron_Group___Policy 
<https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy>)

        Thanks!

        [1]
        
http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/044283.html
        
<http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html>
        [2]
        
http://lists.openstack.org/__pipermail/openstack-dev/2014-__August/043577.html
        
<http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html>


    Hi all,

    IIRC, Kevin was saying to me in IRC that GBP really needs to live
    in-tree due to it needing access to various internal plugin points
    and to be able to call across different plugin layers/drivers inside
    of Neutron.

    If this is the case, how would the stackforge GBP project work if it
    wasn't a fork of Neutron in its entirety?

    Just curious,
    -jay


    _________________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.__org
    <mailto:OpenStack-dev@lists.openstack.org>
    http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>




--
Kevin Benton


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


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

Reply via email to