Hi Salvatore: Comments inline as well
> This is a bit obscure to me. I read it as you're hinting the core team or part of it has double standards. > In that case I would invite you to clarify. 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. 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). 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 "something as core and central to neutron as refactoring ..." 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. > I am not entirely sure what kind of v3 APIs you're referring to. 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. > I don't see a mandatory relationship between pecan and taskflow. I don't see a relationship either. I, simplistically, put all the following issues in the refactoring bucket: 1. Paste + stuff => Pecan 2. V2 => V3 3. Taskflow 4. Cleaning up of distributes locks 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. > 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. I understand. Regards, Mandeep On Wed, May 21, 2014 at 4:02 PM, Salvatore Orlando <sorla...@nicira.com>wrote: > Some comments inline, > > Salvatore > > On 21 May 2014 15:23, Mandeep Dhami <dh...@noironetworks.com> wrote: > >> Hi Sean: >> >> 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. >> > > This is a bit obscure to me. I read it as you're hinting the core team or > part of it has double standards. > In that case I would invite you to clarify. > > >> >> It is my opinion, and my recommendation, that the proposed changes be >> documented and reviewed by same standard that we have for other features. >> > > 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. > > >> >> * I believe that v3 API is being introduced and chnages are being made, >> but I might have mis-understood. >> > > I am not entirely sure what kind of v3 APIs you're referring to. > I think no changes to existing subnet/router/floating IPs APIs and object > models have been proposed so far. > Anyway, I was not at the summit either, so my information might not be > accurate. > > ** 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. >> > > I don't see a mandatory relationship between pecan and taskflow. > 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. > > >> >> >> Regards, >> mandeep >> >> >> >> On Wed, May 21, 2014 at 6:52 AM, Collins, Sean < >> sean_colli...@cable.comcast.com> wrote: >> >>> On Tue, May 20, 2014 at 05:18:57PM EDT, Mandeep Dhami wrote: >>> > Renewing the thread, is there a blueprint for this refactoring effort? >>> > >>> > In the email thread till now, we have just had an etherpad link. I >>> would >>> > like to get more deeply involved in design/implementation and review of >>> > these changes and I get a feeling that not being able to attend the >>> Atlanta >>> > summit is going to be a significant barrier to participation in this >>> > critical effort. >>> >>> >>> It is possible there is a misconception here: refactoring the API core >>> does >>> not mean changing the APIs that are presented to the user. We are in the >>> process of replacing a homegrown WSGI with Pecan to make the WSGI layer >>> of Neutron cleaner and easier to create API extensions. >>> >>> http://pecan.readthedocs.org/en/latest/index.html >>> >>> -- >>> Sean M. Collins >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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
