Open Stack

And while we are on this, just wanted to remind all those interested
to attend the weekly GBP meeting later today:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

On Wed, Aug 6, 2014 at 8:12 PM, Mike Cohen <cohen at noironetworks.com> wrote:
> Its good to see such a lively debate about this topic.  With the disclaimer
> of someone who has worked on this project, I have a strong preference
> towards Option 1 as well (ie. merging it in the tree).  We’ve actually
> already heard from users on this thread who want to use this([1] and [2]),
> others who have at least expressed some interest ([3]).   Making it easier
> for them to consume it is a very much worth the effort.
>
> You’ll also see a strong willingness from our team to compromise on things
> like naming conventions (endpoints can certainly become something else to
> avoid confusion for example) and labels the community wants to place on this
> in terms of support (maybe a “beta” or “preview” disclaimer) so it does not
> send the wrong message to users.
>
> From our group’s perspective, we’re happy to see the discussion occur so
> everyone can weigh in but we also are seeking *closure* on this topic,
> especially considering we have operators asking for it and we have limited
> time to actually merge it in Juno-3.  Hopefully we can achieve this closure
> asap so we can move forward with our work (both on this project and other
> Neutron projects).
>
> Thanks,
> Mike
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/042036.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/042043.html
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/042180.html
>
>
> From: Stephen Wong <stephen.kf.wong at gmail.com>
>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: Wednesday, August 6, 2014 at 9:03 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the
> way forward
>
> Hi,
>
>     Thanks to Armando for steering the discussion back to the original
> intent.
>
>
> On Wed, Aug 6, 2014 at 3:56 PM, Armando M. <armamig at gmail.com> wrote:
>>
>>
>> On 6 August 2014 15:47, Kevin Benton <blak111 at gmail.com> wrote:
>>>
>>> I think we should merge it and just prefix the API for now with
>>> '/your_application_will_break_after_juno_if_you_use_this/'
>>
>>
>> And you make your call based and what pros and cons exactly, If I am ask?
>>
>> Let me start:
>>
>> Option 1:
>>   - pros
>>     - immediate delivery vehicle for consumption by operators
>
>
>     Buried inside these 100+ posts are posts from two OpenStack users
> pleading for their desire to use GBP APIs for their Juno deployments. While
> that is a small sample size, it does prove that there is legitimate
> interests from our user base to get their hands on this feature.
>
>     User feedback is the best way to evolve the APIs moving forward - as
> long as these APIs/implementation do not jeopardize the stability of
> Neutron. And as many folks in the thread had pointed out, the GBP
> implementation currently has really gone the extra mile to ensure it does
> NOT do that.
>
>
>>
>>   - cons
>>     - code is burder from a number of standpoints (review, test, etc)
>
>
>     This is a legitimate concern - that said, if you take a look at the
> first patch:
>
> https://review.openstack.org/#/c/95900/
>
>     there are 30 human reviewers (non-CI) signed up to review the patch at
> this time, and among them 9 Neutron core members (8 if you don't count
> Sumit, who is the author), as well as a Nova core. From the reception, I
> believe the community does not generally treat reviewing GBP related patches
> as a burden, but likely as an item of interest. Additionally, with such
> board and strong community base willing to involve in reviewing the code, I
> think with these "many eyes" it will hopefully help lessen the burden on
> Neutron cores to review and merge these set of patches.
>
>
>>
>>
>> Option 2:
>>   - pros
>>     - enable a small set of Illuminati to iterate faster
>
>
>
>     As a subgroup, we have already iterated the model and APIs for about a
> year, with around 40 IRC meetings for community discussions, a PoC demo that
> was presented to about 300 audiences back at J-Summit, and actual
> implementations in gerrit for months now. Indeed with about 35+ people
> responding to this thread, I have yet to see anyone making a claim that "GBP
> model and APIs as they are now are crap, we have to scrap it and rethink". I
> would like to think that we are at a point where we will do phase by phase
> enhancements - as should practically any other APIs in OpenStack - rather
> than rapid iterations within a cycle. While we already have some user
> feedbacks, we would love to get more and more user and developer community
> feedbacks to evolve GBP to better fit their needs, and stackforge
> unfortunately does not serve that purpose well.
>
>
>>
>>   - cons
>>     - integration burden with other OpenStack projects (keystone, nova,
>> neutron, etc)
>
>
>
>     That is indeed a major con - evidenced by the fact that the number of
> Nova folks joining the discussion on this thread to express integration
> concern. We would like to get GBP integration with other OpenStack projects
> done as soon as possible. As you pointed out, stackforge is a terrible
> option as it pushes the burden of this integration to much later, which
> inevitably will incur much higher integration costs moving forward.
>
> Thanks,
> - Stephen
>
>
>>
>>
>> Cheers,
>> Armando
>>
>> _______________________________________________
>> 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
>