Being in the incubator won't help with this if it's a different repo as well.
On Wed, Sep 10, 2014 at 7:22 AM, Robert Kukura <[email protected]> wrote: > > On 9/9/14, 7:51 PM, Jay Pipes wrote: > >> 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! >> > I'll add that there is likely to be a close coupling between ML2 mechanism > drivers and corresponding GBP policy drivers for some of the back-end > integrations. These will likely share local state such as connections to > controllers, and may interact with each other as part of processing core > and GBP API requests. Development, review, and packaging of these would be > facilitated by having them on the same branch in the same repo, but its > probably not absolutely necessary. > > -Bob > > >> Best, >> -jay >> >> On Tue, Sep 9, 2014 at 12:01 PM, Jay Pipes <[email protected] >>> <mailto:[email protected]>> 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 >>> [email protected].__org >>> <mailto:[email protected]> >>> 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
