Open Stack

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 <jaypipes at gmail.com
> <mailto:jaypipes at 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 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>
>
>
>
>
> --
> Kevin Benton
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>