<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 22 May 2014 03:47, 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"><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 class=""><div>
<div 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 style="font-size:small;display:inline">> </div>In that case I would invite you to clarify.</div>
<div><br></div></div><div><div 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></div></div></div></div></div></blockquote><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 style="font-family:arial,sans-serif;font-size:13px">
<div class="gmail_extra"><div class="gmail_quote"><div><div style="font-size:small"><br></div><div 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. </div>
</div></div></div></div></div></div></blockquote><div><br></div><div>I don't think so. For instance we have a lot of blueprints for internal agent changes. A blueprint is required for any new feature or any change which affects in a non trivial way internal or external interfaces or the architecture of a component.</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 style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_extra">
<div class="gmail_quote"><div><div style="font-size:small">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 style="font-size:small"><br></div><div 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></div></div></div></div></blockquote><div><br></div><div>There is no need to make a big deal of this. I just wrote that this could have been read in that way, not that it was that way.</div><div>I asked for a clarification, and you did it. That's it!</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 style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_extra">
<div class="gmail_quote"><div>
</div><div class=""><div style="font-size:small"><br></div><div><div 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><div 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></div></div></div></div></blockquote><div><br></div><div>Sorry - my bad. I mixed up "L3" and "v3"; unfortunately despite visiting several doctors I still can't resist the urge of getting drunk while reading the neutron mailing list!</div>
<div>It has been discussed, but given the delicate nature of the topic, and the number of high priority items already on the plate, it's really unlikely to end up in the Juno roadmap.<br></div><div>I thing however discussion on shaping the API should be encouraged.</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 style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_extra">
<div class="gmail_quote"><div>
</div><div class=""><div><div><br></div></div><div><div style="font-size:small;display:inline">> </div>I don't see a mandatory relationship between pecan and taskflow.</div><div><br></div></div><div>
<div style="font-size:small">I don't see a relationship either. I, simplistically, put all the following issues in the refactoring bucket:</div><div style="font-size:small">
1. Paste + stuff => Pecan</div><div style="font-size:small">2. V2 => V3</div><div style="font-size:small">3. Taskflow</div><div style="font-size:small">
4. Cleaning up of distributes locks</div></div></div></div></div></div></div></blockquote><div><br></div><div>Well, they might all be "refactoring: in a way - but they're definitely different buckets. Also, the second items is actually constituted by two big tickets, and none of them should be, in my opinion, in the Juno roadmap: one side there is the v3 tenant API, and on the other side the v3 plugin interface. I think Mark presented some code snippets for this as well.</div>
<div>If I understand the fourth topic correctly, the issue is probably that Neutron's database management is not:</div><div>- deadlock-safe</div><div>- prone to lock wait timeout errors due to eventlet switches during transactions</div>
<div>- not friendly to active/active replication</div><div>For this particular topic I think both a short term fix than a longer term refactoring are being discussed. A few patches concerning lock wait timeout errors have already been merged.</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 style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_extra">
<div class="gmail_quote"><div><div style="font-size:small"></div><div style="font-size:small"><br></div><div 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 style="font-size:small"><br></div></div></div></div></div></div></div></blockquote><div>As stated before, any change which impact the current architecture of the software, or changes in a non trivial way any interface, be it internal or external, should be accompanied by a specification that will be available for review on neutron-specs repo.</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 style="font-family:arial,sans-serif;font-size:13px"><div class="gmail_extra">
<div class="gmail_quote"><div><div style="font-size:small"></div><div style="font-size:small"><br></div><br></div><div><div 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 style="font-size:small;display:inline">> </div> the <div 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 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 style="font-size:small;display:inline">
> </div>running today.</div><div><br></div><div><div style="font-size:small">I understand.</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><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>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>
<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>
<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>
<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>
<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" 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><br></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>