Open Stack

On Sat, Sep 6, 2014 at 9:54 AM, Prasad Vellanki <
prasad.vellanki at 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 <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
>>
>>
>
> _______________________________________________
> 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/20140909/7694a663/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/20140909/7694a663/attachment.gif>