I agree with Kevin. Like in Juno, we as a subteam will be shooting for option 1 (again) for Kilo - ideally we can land in Kilo, and we will work closely with the community to try to accomplish that. In the meantime, we need to have a repo to iterate our implementations, build package (Juno based) to early adopters, and be as transparent as if the code is on gerrit. With option 2 never picking up momentum when Bob suggested it on the ML, option 3 being more like an idea discussed by several cores during the mid-cycle meetup, and option 4 is currently on holding pattern without any detail but tons of concern raised on ML --- option 5 (stackforge) seems like the best available option at this point.
Thanks, - Stephen On Thu, Sep 11, 2014 at 10:02 AM, Kevin Benton <blak...@gmail.com> wrote: > Thanks. This is good writeup. > > >Of course this all assumes there is consensus that we should proceed > with GBP, that we should continue by iterating the currently proposed > design and code, and that GBP should eventually become part of Neutron. > These assumptions may still be the real issues :-( . > > Unfortunately I think this is the real root cause. Most of the people that > worked on GBP definitely want to see it merged into Neutron and is in > general agreement there. However, some of the other cores disagreed and now > GBP is sitting in limbo. IIUC, this thread was started to just get GBP to > some location where it can be developed on and tested that isn't a big > string of rejected gerrit patches. > > >Does the above make some sense? What have I missed? > > Option 1 is great, but I don't see how the same thing that happened in > Juno would be avoided. > > Option 2 is also good, but that idea didn't seem to catch on. If this > option is on the table, this seems like the best way to go. > > Option 3 sounded like it brought up a lot of tooling (gerrit) issues with > regard to how the merging workflow would work. > > Option 4 is unknown until the incubator details are hashed out. > > Option 5 is stackforge. I see this as a better place just to do what is > already being done right now. You're right that patches would occur without > core reviewers, but that's essentially what's happening now since nothing > is getting merged. > > > > > On Thu, Sep 11, 2014 at 7:57 AM, Robert Kukura <kuk...@noironetworks.com> > wrote: > >> >> On 9/10/14, 6:54 PM, Kevin Benton wrote: >> >> Being in the incubator won't help with this if it's a different repo as >> well. >> >> Agreed. >> >> Given the requirement for GBP to intercept API requests, the potential >> couplings between policy drivers, ML2 mechanism drivers, and even service >> plugins (L3 router), and the fact Neutron doesn't have a stable [service] >> plugin API, along with the goal to eventually merge GBP into Neutron, I'd >> rank the options as follows in descending order: >> >> 1) Merge the GBP patches to the neutron repo early in Kilo and iterate, >> just like we had planned for Juno ;-) . >> >> 2) Like 1, but with the code initially in a "preview" subtree to clarify >> its level of stability and support, and to facilitate packaging it as an >> optional component. >> >> 3) Like 1, but merge to a feature branch in the neutron repo and iterate >> there. >> >> 4) Develop in an official neutron-incubator repo, with neutron core >> reviews of each GBP patch. >> >> 5) Develop in StackForge, without neutron core reviews. >> >> >> Here's how I see these options in terms of the various considerations >> that have come up during this discussion: >> >> * Options 1, 2 and 3 most easily support whatever coupling is needed with >> the rest of Neutron. Options 4 and 5 would sometimes require synchronized >> changes across repos since dependencies aren't in terms of stable >> interfaces. >> >> * Options 1, 2 and 3 provide a clear path to eventually graduate GBP into >> a fully supported Neutron feature, without loss of git history. Option 4 >> would have some hope of eventually merging into the neutron repo due to the >> code having already had core reviews. With option 5, reviewing and merging >> a complete GBP implementation from StackForge into the neutron repo would >> be a huge effort, with significant risk that reviewers would want design >> changes not practical to make at that stage. >> >> * Options 1 and 2 take full advantage of existing review, CI, packaging >> and release processes and mechanisms. All the other options require extra >> work to put these in place. >> >> * Options 1 and 2 can easily make GBP consumable by early adopters >> through normal channels such as devstack and OpenStack distributions. The >> other options all require the operator or the packager to pull GBP code >> from a different source than the base Neutron code. >> >> * Option 1 relies on the historical understanding that new Neutron >> extension APIs are not initially considered stable, and incompatible >> changes can occur in future releases. Options 2, 3 and 4 make this >> explicit. Option 5 really has nothing to do with Neutron. >> >> * Option 5 allows rapid iteration by the GBP team, without waiting for >> core review. This is essential during experimentation and prototyping, but >> at least some participants consider the GBP implementation to be well >> beyond that phase. >> >> * Options 3, 4, and 5 potentially decouple the GBP release schedule from >> the Neutron release schedule. With options 1 or 2, GBP snapshots would be >> included in all normal Neutron releases. With any of the options, the GBP >> team, vendors, or distributions would be able to back-port arbitrary >> snapshots of GBP to a branch off the stable/juno branch (in the neutron >> repo itself or in a clone) to allow early adopters to use GBP with >> Juno-based OpenStack distributions. >> >> >> Does the above make some sense? What have I missed? >> >> Of course this all assumes there is consensus that we should proceed with >> GBP, that we should continue by iterating the currently proposed design and >> code, and that GBP should eventually become part of Neutron. These >> assumptions may still be the real issues :-( . If we can't agree on >> whether GBP is in an experimentation/rapid-prototyping phase vs. an >> almost-ready-to-beta-test phase, I don't see how can we get consensus on >> the next steps for its development. >> >> -Bob >> >> >> On Wed, Sep 10, 2014 at 7:22 AM, Robert Kukura <kuk...@noironetworks.com> >> 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 <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 >>>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> -- >> Kevin Benton >> >> >> _______________________________________________ >> OpenStack-dev mailing >> listOpenStack-dev@lists.openstack.orghttp://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 >> >> > > > -- > 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