<div dir="ltr">Hi,<div><br></div><div> Thanks to Armando for steering the discussion back to the original intent. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 3:56 PM, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">
<div class="">
On 6 August 2014 15:47, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p dir="ltr">I think we should merge it and just prefix the API for now with '/your_application_will_break_after_juno_if_you_use_this/' <br>
</p><div><div>
<div class="gmail_quote"></div></div></div></blockquote><div><br></div></div>And you make your call based and what pros and cons exactly, If I am ask?<div><br></div><div>Let me start:</div><div><br></div><div>Option 1:</div>
<div>
- pros</div>
<div> - immediate delivery vehicle for consumption by operators</div></div></div></div></blockquote><div><br></div><div> 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.</div>
<div><br></div><div> 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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div> - cons</div><div> - code is burder from a number of standpoints (review, test, etc)</div></div></div></div></blockquote><div><br></div><div> This is a legitimate concern - that said, if you take a look at the first patch:</div>
<div><br></div><div><a href="https://review.openstack.org/#/c/95900/">https://review.openstack.org/#/c/95900/</a><br></div><div><br></div><div> 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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><br></div><div>Option 2:</div><div> - pros</div>
<div> - enable a small set of Illuminati to iterate faster </div></div></div></div></blockquote><div><br></div><div><br></div><div> 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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div> - cons</div><div> - integration burden with other OpenStack projects (keystone, nova, neutron, etc)</div></div></div></div></blockquote><div><br></div><div><br></div><div> 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.</div>
<div><br></div><div>Thanks,</div><div>- Stephen</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Cheers,</div><div>
Armando</div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>