On Tue, Oct 4, 2016 at 5:38 PM, Anil Vishnoi <vishnoia...@gmail.com
<mailto:vishnoia...@gmail.com>> wrote:
Hi Brady,
Please see inline..
On Tue, Oct 4, 2016 at 12:47 PM, Brady Johnson
<bradyallenjohn...@gmail.com <mailto:bradyallenjohn...@gmail.com>>
wrote:
Anil,
We're talking about 2 different patches here.
I remember patch [0] well, and the discussions around it,
which you quoted above. Im not that old yet ;) This patch is
the Neutron Northbound API.
I dont remember ever hearing anything about patch [1] though.
This patch is the */implementation/* of the Northbound API
from patch [0]. I was under the impression that the
implementation was going to be put in ODL SFC.
Not sure how you got this impression, given that the only
response we got was pretty strong against this idea :-).
Agreed, though I recall something along the lines of "as long as the
odl sfc models are left alone do whatever". We didn't have any other
feedback and Anil needed to make progress so we did what we could to
move forward.
"
>/This ISN’T you exercising the right to do your own implementation
of Neutron SFC, this is introducing an unwanted API dependency on
ODL-SFC./
>//>/So now if ODL SFC needs/wants to change its YANG models due to say
IETF / sanity, and those don’t magically line up with
neutron-sfc’s bizarre view of the world, or at least one beyond
1999-2001 when this sort of approach to SFC was first proposed, we
get blocked from doing so because it will break this “translation
layer” that now has welded an unwanted dependency on the project. /
>"
Considering the patch is experimental as you mentioned, I can
see why you didnt publish it.
This patch was out there in the open for everyone to review in
NetVirt master branch, so anyone can review these patch. Going
forward we will add all the sfc committers as a reviewer in the
NetVirt patches that is related to SFC work, so that they can
easily monitor those patches. Hopefully that won't create much
spam for them.
Agreed here also. The patches sat around for a while and were in the
open. It was an oversight that more reviewers were not included - that
is something we need to be better about.
Can you please mark experimental patches as such in the future
to avoid confusion.
Yup, i think that's useful to have.
Also, It wouldnt hurt to mention why its being self-merged.
Agree, what standard practice SFC project use?, we can probably
follow the same in net-virt project ?
To be fair, I reviewed the patch but didn't have substantial comments.
Anil and I talked about it and I said it was OK to merge.
These additional comments would have probably saved some work
for Alexis too.
I think alexis comments were very valid comments, so i think his
time was well spent :).
As you can imagine, the ODL SFC community is very interested
to see how the implementation of patch [0] works out. I was
hoping it would be possible to wait until Networking SFC
aligned with either IETF SFC or ETSI VNFFG, else we risk not
being able to completely leverage ODL SFC, since the
Networking SFC API is very basic and lacking to say the least.
I think it's a longer discussion that need to be done across
openstack/opendaylight/opnfv. I am not sure what are the concrete
steps are taken by networking-sfc project to move toward this
direction. I saw one blueprint in this direction, but it was
abandoned later on. I think there is a long way ahead to get to
those final api we are expecting, and i think this requires some
effort from teh provider side to implement the available API's and
provide the feedback to the networking-sfc. I think that way we
can make faster progress.
As you know the APIs have been taking some time to settle, so we moved
ahead with what we had at the time and made sure not to impact odl
sfc. That seems to be what you are concerned with so I think we met
that need.
In the future, could you please inform us of any additional
work in this area so we can help and advise if needed.
Sure will do, please keep watching the sfc-dev mailing list ;).
Thanks,
Brady
[0] https://git.opendaylight.org/gerrit/#/c/38748/
<https://git.opendaylight.org/gerrit/#/c/38748/>
[1] https://git.opendaylight.org/gerrit/#/c/43305/
<https://git.opendaylight.org/gerrit/#/c/43305/>
On Tue, Oct 4, 2016 at 8:05 PM, Anil Vishnoi
<vishnoia...@gmail.com <mailto:vishnoia...@gmail.com>> wrote:
Hi Brady,
Sorry to say, but most of the questions that you asked
below is really a surprise to me as well, given that you
were well aware of the overall networking-sfc integration
work and translation layer work that i was doing and *it
was discussed on sfc-dev mailing list. *Even you were
reviewer of the first ever patch that I pushed in ODL to
start this work.
https://git.opendaylight.org/gerrit/#/c/38748/
<https://git.opendaylight.org/gerrit/#/c/38748/>
Please see inline...
On Tue, Oct 4, 2016 at 12:30 AM, Brady Allen Johnson
<brady.allen.john...@ericsson.com
<mailto:brady.allen.john...@ericsson.com>> wrote:
I just noticed a /*merged*/ Gerrit patch in Netvirt
[0] to do the Networking SFC to ODL SFC conversion.
I have to say that I was quite surprised to see that
this patch was merged without ever consulting the ODL
SFC community. I have a few questions regarding this
patch:
1. Why is this code in Netvirt and not in SFC where
it belongs?
Following thread actually discuss about why we
implemented this translation layer it in netvirt and not
in sfc project. To explictly mention here, I came to SFC
project with the intent of implementing this layer in ODL
SFC project as one of your response says in the mail thread
/
"
As for implementations of the "translation layer", I think
Anil /
/envisioned this to live in ODL SFC, and in any other
projects that wanted to implement their own form of SFC.
Regards, Brady
"
/
Thread:*https://lists.opendaylight.org/pipermail/sfc-dev/2016-May/002998.html
<https://lists.opendaylight.org/pipermail/sfc-dev/2016-May/002998.html>*
If you read through this mail thread, keith was the only
sfc committer who provided his feedback and he was not in
favor of implementing this layer in the sfc project. We
did not get any vote/opinion from you on this subject, and
the only feedback we got was not in favor of the idea, so
that's the reason we decided to implement it in netvirt
and you were very well aware of that as well.
1. Why wasnt the SFC community ever informed about
these changes?
I think this is not correct, I notified opendaylight sfc
community even when I pushed blueprint for networking-sfc
driver to openstack networking-sfc project. Here is the
mail thread
https://lists.opendaylight.org/pipermail/sfc-dev/2016-April/002833.html
<https://lists.opendaylight.org/pipermail/sfc-dev/2016-April/002833.html>
Apart from that you were reviewer on the gerrit i
mentioned above, and that was the first patch on the ODL
side that I pushed for networking-sfc support.
1.
2. Why was the patch +2'd and merged by the author?
Unless things have changed drastically lately,
self-merging is frowned upon, and in most projects
its simply /*not allowed*/.
This is the first experimental version that we added for
networking-sfc API support. Nature of this work was a
experimental moreover to analyze the gap between
networking-sfc and odl SFC API's and provide more feedback
to networking-sfc project to improve their APIs. And Sam
and I agreed on this that we can self merge this patch,
given that it's totally isolated piece of work and don't
interfere with netvirt project's functionality or ODL SFC
project. Apart from that, sam did review initial patches
with me before i merge these patches.
1. There are some code review comments on the patch
that were never addressed, will these ever be
addressed?
As alexis mentioned in his comment below, he posted this
comment recently (Sep 17)
and patches were merged on Aug 8 (before M5). I generally
don't revisit my merged patches for comments, and likely
most of the developers too, and that's the reason i
probably have missed it. Alexis comment is already
partially addressed in other patches.
1.
Needless to say, this has left a nasty taste in my
mouth. Hopefully we can set this straight and start
collaborating between projects in the future.
Definitely, That was my primary intend, but unfortunately
we didn't get much enthusiastic response from sfc
committers. Looking forward to a better collaboration in
future.
I am assuming that you are totally swamped with the mails
and probably missed some of the mail thread i mentioned
above, let me know if i can communicate with you by some
other means that works better for you.
Regards, Brady [0]
https://git.opendaylight.org/gerrit/#/c/43305/
<https://git.opendaylight.org/gerrit/#/c/43305/>
--
Thanks
Anil
_______________________________________________ sfc-dev
mailing list sfc-dev@lists.opendaylight.org
<mailto:sfc-dev@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
<https://lists.opendaylight.org/mailman/listinfo/sfc-dev>
--
Thanks
Anil
_______________________________________________ netvirt-dev
mailing list netvirt-...@lists.opendaylight.org
<mailto:netvirt-...@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/netvirt-dev
<https://lists.opendaylight.org/mailman/listinfo/netvirt-dev>
_______________________________________________
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev
