<div dir="ltr"><div class="gmail_default" style="font-size:small"><span style="font-family:arial,sans-serif;font-size:13px">Hi Salvatore:</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
Comments inline as well</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail_default" style="font-size:small;display:inline">
> </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><div class="gmail_default" style="font-size:small;display:inline">> </div>In that case I would invite you to clarify.</div>
<div><br></div><div><div class="gmail_default" style="font-size:small">Last week, I had requested reference to a design document for neutron refactoring work. As this is a critical change, I wanted to understand what was being proposed (and hopefully contribute to it's implementation). The only feedback I received was about the etherpad of the meeting, and I was hoping for more. I re-requested it again, yesterday, just in case my request had got buried under all summit related email that everyone was so busy with last week.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The update from Sean seem to suggest to me that we needed blueprints only if the public API changes, and not for design changes that are internal to neutron. My comments were meant to extol the "virtue" of creating a design document, and reviewing all significant design changes, even for updates that do not change the public API. In that context, I was trying to make a point that reviews should be prioritized by importance/impact to the project and not based on any other criteria (like, say a delta difference from previous spec - something which would be triggered by a simple name change - and something that thought that I had seen in a review just that very day).</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">When I sent that email I did not know who was working it, there was no aspersion cast or implied. The only mention of "core" was in "<span style="color:rgb(80,0,80)">something as core and central to neutron as refactoring ...</span>" and I never mentioned the core team. If you are working on it, I apologize if it came across that way to you. At the same time, I am not comfortable with the conclusion that you drew about my intentions. I am happy to address this face-to-face if that helps (or hangout to hangout) - I am not that adroit with emails and I worry that my response may again be misunderstood.</div>
</div><div class="gmail_default" style="font-size:small"><br></div><div><div class="gmail_default" style="font-size:small;display:inline">> </div>I am not entirely sure what kind of v3 APIs you're referring to.</div>
<div><br></div><div><div class="gmail_default" style="font-size:small">My understanding was that there was a proposal for a V3 API. But based on Mark Mclain's response to this thread that is probably now slated for K-release.</div>
</div><div class="im"><div><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">> </div>I don't see a mandatory relationship between pecan and taskflow.</div><div><br></div><div>
<div class="gmail_default" style="font-size:small">I don't see a relationship either. I, simplistically, put all the following issues in the refactoring bucket:</div><div class="gmail_default" style="font-size:small">
1. Paste + stuff => Pecan</div><div class="gmail_default" style="font-size:small">2. V2 => V3</div><div class="gmail_default" style="font-size:small">3. Taskflow</div><div class="gmail_default" style="font-size:small">
4. Cleaning up of distributes locks</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">No relationship between them is necessarily implied (either in design or in timing). I figured that any refactoring effort will have to design solution for each of them and then weigh priority based on effort/risk/impact/value of each of those changes. I suspect that there are more - that was just what I understood to be urgent or important.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">> </div>There was a session discussing the possibility of having a task based interaction between the front end and</div>
<div><div class="gmail_default" style="font-size:small;display:inline">> </div> the <div class="gmail_default" style="font-size:small;display:inline"></div>backend - taskflow would be a candidate task manager solution there. But from what I gathered this was</div>
<div><div class="gmail_default" style="font-size:small;display:inline">></div> orthogonal to the Pecan effort, which is merely a replacement of the home-grown wsgi framework neutron is</div><div><div class="gmail_default" style="font-size:small;display:inline">
> </div>running today.</div><div><br></div><div><div class="gmail_default" style="font-size:small">I understand.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Regards,</div><div class="gmail_default" style="font-size:small">Mandeep</div><div class="gmail_default" style="font-size:small"><br></div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, May 21, 2014 at 4:02 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.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>Some comments inline,</div><div><br></div><div>Salvatore<div class="gmail_extra"><br><div class="gmail_quote"><div class="">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><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 class="">
<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><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 class="">
<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><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 class="">
<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><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 class="h5">
<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><div><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" 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>
<br></blockquote></div></div></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>