<div dir="ltr"><div>Some comments inline,</div><div><br></div><div>Salvatore<div class="gmail_extra"><br><div class="gmail_quote">On 21 May 2014 15:23, Mandeep Dhami <span dir="ltr"><<a href="mailto:dhami@noironetworks.com" target="_blank">dhami@noironetworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">Hi Sean:</div><div style="font-size:small"><br></div><div style="font-size:small">
While the APIs might not be changing*, I suspect that there are significant design decisions being made**. These changes are probably more significant than any new feature being discussed. As a community, are we expected to document these design changes and review these changes as well? I am still trying to figure out what Neutron's review standards are. On one hand, I am seeing code review comments that reject a patch for cosmetic changes (like a name change from what was in the reviewed blueprint), to having an attitude that something as core and central to neutron as refactoring and a major API update to v3 not needing a design document/review.</div>
</div></blockquote><div><br></div><div>This is a bit obscure to me. I read it as you're hinting the core team or part of it has double standards.</div><div>In that case I would invite you to clarify.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div style="font-size:small"><br></div><div style="font-size:small">It is my opinion, and my recommendation, that the proposed changes be documented and reviewed by same standard that we have for other features.</div></div>
</blockquote><div><br></div><div>As for any other change requiring a blueprint, they will obviously be submitted to neutron-specs and reviewed; as long as they're not there, they do not exist.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div style="font-size:small"><br></div><div style="font-size:small">* I believe that v3 API is being introduced and chnages are being made, but I might have mis-understood.</div></div></blockquote><div><br></div><div>I am not entirely sure what kind of v3 APIs you're referring to.</div>
<div>I think no changes to existing subnet/router/floating IPs APIs and object models have been proposed so far.</div><div>Anyway, I was not at the summit either, so my information might not be accurate.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div style="font-size:small">** I was under the impression that in addition to the Pecan updates, there was going to be refactoring to use taskflow as well. And that I expect to have significant control flow impact, and that is what I really wanted to review.<br>
</div></div></blockquote><div><br></div><div>I don't see a mandatory relationship between pecan and taskflow.</div><div>There was a session discussing the possibility of having a task based interaction between the front end and the backend - taskflow would be a candidate task manager solution there. But from what I gathered this was orthogonal to the Pecan effort, which is merely a replacement of the home-grown wsgi framework neutron is running today.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">
</div><div style="font-size:small"><br></div><div style="font-size:small"><br></div><div style="font-size:small">Regards,</div><div style="font-size:small">
mandeep</div><div style="font-size:small"><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 21, 2014 at 6:52 AM, Collins, Sean <span dir="ltr"><<a href="mailto:Sean_Collins2@cable.comcast.com" target="_blank">Sean_Collins2@cable.comcast.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, May 20, 2014 at 05:18:57PM EDT, Mandeep Dhami wrote:<br>
> Renewing the thread, is there a blueprint for this refactoring effort?<br>
><br>
> In the email thread till now, we have just had an etherpad link. I would<br>
> like to get more deeply involved in design/implementation and review of<br>
> these changes and I get a feeling that not being able to attend the Atlanta<br>
> summit is going to be a significant barrier to participation in this<br>
> critical effort.<br>
<br>
<br>
</div>It is possible there is a misconception here: refactoring the API core does<br>
not mean changing the APIs that are presented to the user. We are in the<br>
process of replacing a homegrown WSGI with Pecan to make the WSGI layer<br>
of Neutron cleaner and easier to create API extensions.<br>
<br>
<a href="http://pecan.readthedocs.org/en/latest/index.html" target="_blank">http://pecan.readthedocs.org/en/latest/index.html</a><br>
<span><font color="#888888"><br>
--<br>
Sean M. Collins<br>
</font></span><div><div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div></div></blockquote></div><br></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></div>