Hi,
Thanks to Armando for steering the discussion back to the original
intent.
On Wed, Aug 6, 2014 at 3:56 PM, Armando M. <arma...@gmail.com> wrote:
>
> On 6 August 2014 15:47, Kevin Benton <blak...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
