Open Stack

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
<http://lists.openstack.org/pipermail/openstack-dev/2014-August/042036.html>*
[2] *http://lists.openstack.org/pipermail/openstack-dev/2014-August/042043.html
<http://lists.openstack.org/pipermail/openstack-dev/2014-August/042043.html>*
[3] *http://lists.openstack.org/pipermail/openstack-dev/2014-August/042180.html
<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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/c7cd6488/attachment.html>
-------------- next part --------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev