Open Stack

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 <sorlando at nicira.com>wrote:

> Some comments inline,
>
> Salvatore
>
> On 21 May 2014 15:23, Mandeep Dhami <dhami at 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_Collins2 at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140521/b6b99056/attachment.html>