Open Stack

On 22 May 2014 03:47, Mandeep Dhami <dhami at noironetworks.com> wrote:

> 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.
>

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.


> 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.
>

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.
I asked for a clarification, and you did it. That's it!


>
> ​> ​
> 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.
>

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!
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.
I thing however discussion on shaping the API should be encouraged.


>
> ​> ​
> 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
>

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.
If I understand the fourth topic correctly, the issue is probably that
Neutron's database management is not:
- deadlock-safe
- prone to lock wait timeout errors due to eventlet switches during
transactions
- not friendly to active/active replication
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.

> ​
>
> 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.
>
> 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.


>
>
> ​> ​
> 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
>>
>>
>
> _______________________________________________
> 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/20140522/91404012/attachment.html>