Good discussion. Based on this I think we should get started on the stackforge right away.
Sumit - It would be great if you get started on the StackForge soon. We have a few changes that needs to be submitted and have been holding up. On Fri, Sep 5, 2014 at 8:08 AM, Mohammad Banikazemi <m...@us.ibm.com> wrote: > I can only see the use of a separate project for Group Policy as a > tactical and temporary solution. In my opinion, it does not make sense to > have the Group Policy as a separate project outside Neutron (unless the new > project is aiming to replace Neutron and I do not think anybody is > suggesting that). In this regard, Group Policy is not similar to Advanced > Services such as FW and LB. > > So, using StackForge to get things moving again is fine but let us keep in > mind (and see if we can agree on) that we want to have the Group Policy > abstractions as part of OpenStack Networking (when/if it proves to be a > valuable extension to what we currently have). I do not want to see our > decision to make things moving quickly right now prevent us from achieving > that goal. That is why I think the other two approaches (from the little I > know about the incubator option, and even littler I know about the feature > branch option) may be better options in the long run. > > If I understand it correctly some members of the community are actively > working on these options (that is, the incubator and the Neutron feature > branch options) . In order to make a better judgement as to how to proceed, > it would be very helpful if we get a bit more information on these two > options and their status here on this mailing list. > > Mohammad > > > > [image: Inactive hide details for Kevin Benton ---09/05/2014 04:31:05 > AM---Tl;dr - Neutron incubator is only a wiki page with many unce]Kevin > Benton ---09/05/2014 04:31:05 AM---Tl;dr - Neutron incubator is only a wiki > page with many uncertainties. Use StackForge to make progre > > From: Kevin Benton <blak...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: 09/05/2014 04:31 AM > Subject: Re: [openstack-dev] [neutron][policy] Group-based Policy next > steps > ------------------------------ > > > > Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use > StackForge to make progress and re-evaluate when the incubator exists. > > > I also agree that starting out in StackForge as a separate repo is a > better first step. In addition to the uncertainty around packaging and > other processes brought up by Mandeep, I really doubt the Neutron incubator > is going to have the review velocity desired by the group policy > contributors. I believe this will be the case based on the Neutron > incubator patch approval policy in conjunction with the nature of the > projects it will attract. > > Due to the requirement for two core +2's in the Neutron incubator, moving > group policy there is hardly going to do anything to reduce the load on the > Neutron cores who are in a similar overloaded position as the Nova > cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron > incubator receive even less core attention than the main repo simply > because their location outside of openstack/neutron will be a good reason > to treat them with a lower priority. > > If you combine that with the fact that the incubator is designed to house > all of the proposed experimental features to Neutron, there will be a very > high volume of patches constantly being proposed to add new features, make > changes to features, and maybe even fix bugs in those features. This new > demand for reviewers will not be met by the existing core reviewers because > they will be busy with refactoring, fixing, and enhancing the core Neutron > code. > > Even ignoring the review velocity issues, I see very little benefit to GBP > starting inside of the Neutron incubator. It doesn't guarantee any > packaging with Neutron and Neutron code cannot reference any incubator > code. It's effectively a separate repo without the advantage of being able > to commit code quickly. > > There is one potential downside to not immediately using the Neutron > incubator. If the Neutron cores decide that all features must live in the > incubator for at least 2 cycles regardless of quality or usage in > deployments, starting outside in a StackForge project would delay the start > of the timer until GBP makes it into the incubator. However, this can be > considered once the incubator actually exists and starts accepting > submissions. > > In summary, I think GBP should move to a StackForge project as soon as > possible so development can progress. A transition to the Neutron incubator > can be evaluated once it actually becomes something more than a wiki page. > > > 1. > *http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html* > <http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html> > > -- > Kevin Benton > > > On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami <*dh...@noironetworks.com* > <dh...@noironetworks.com>> wrote: > > > I agree. Also, as this does not preclude using the incubator when it > is ready, this is a good way to start iterating on implementation in > parallel with those issues being addressed by the community. > > In my view, the issues raised around the incubator were significant > enough (around packaging, handling of updates needed for > horizon/heat/celiometer, handling of multiple feature branches, etc) that > we we will probably need a design session in paris before a consensus will > emerge around a solution for the incubator structure/usage. And if you are > following the thread on nova for 'Averting the Nova crisis ...', the final > consensus might actually BE to use separate stackforge project for plugins > anyways, and in that case we will have a head start ;-) > > Regards, > Mandeep > ----- > > > On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki < > *prasad.vella...@oneconvergence.com* > <prasad.vella...@oneconvergence.com>> wrote: > Sumit > Thanks for initiating this and also good discussion today on the > IRC. > > My thoughts are that it is important to make this available to > potential users and customers as soon as possible so that we can get the > necessary feedback. Considering that the neutron cores and community are > battling nova parity and stability now, I would think it would be tough > to > get any time for incubator or neutron feature branch any time soon. > I would think it would be better to move GBP into stackforge and > then look at incubator or neutron feature branch when available. > > prasadv > > > On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam < > *sumitnaiksa...@gmail.com* <sumitnaiksa...@gmail.com>> 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> > > _______________________________________________ > OpenStack-dev mailing list > *OpenStack-dev@lists.openstack.org* <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> > > > _______________________________________________ > OpenStack-dev mailing list > *OpenStack-dev@lists.openstack.org* <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> > > > _______________________________________________ > OpenStack-dev mailing list > *OpenStack-dev@lists.openstack.org* <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
