Open Stack

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





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

--
Kevin Benton


On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami <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> 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> 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)

     Thanks!

     [1]
     http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html

     [2]
     http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html


     _______________________________________________
     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



  _______________________________________________
  OpenStack-dev mailing list
  OpenStack-dev at lists.openstack.org
  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140905/2d20f426/attachment-0001.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/20140905/2d20f426/attachment-0001.gif>