[openstack-dev] [neutron][policy] Group-based Policy next steps
Baohua Yang
yangbaohua at gmail.com
Wed Sep 10 03:06:47 UTC 2014
Agree.
It's necessary for neutron to have GBP, and we can certainly utilize
stackforge to help improve it.
On Fri, Sep 5, 2014 at 11:08 PM, Mohammad Banikazemi <mb at 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 <blak111 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <*dhami at noironetworks.com*
> <dhami at 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.vellanki at oneconvergence.com*
> <prasad.vellanki at 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 <
> *sumitnaiksatam at gmail.com* <sumitnaiksatam at 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 at lists.openstack.org* <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>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <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>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> *OpenStack-dev at lists.openstack.org* <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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Best wishes!
Baohua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/b38c2c72/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/b38c2c72/attachment.gif>
More information about the OpenStack-dev
mailing list