On Sat, Sep 6, 2014 at 9:54 AM, Prasad Vellanki < prasad.vella...@oneconvergence.com> wrote:
> 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. > > The stackforge repo has been created: https://github.com/stackforge/group-based-policy > 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev