Re: [sfc-dev] [netvirt-dev] Networking SFC convertor in ODL

[Anil Vishnoi]

On Wed, Oct 5, 2016 at 12:16 AM, Brady Allen Johnson <
brady.allen.john...@ericsson.com> wrote:

>
> This discussion isnt really going anywhere.
>
> As you can imagine, its not feasible for us to follow the Netvirt Gerrits.
> Even thought the patch [0] was indeed available for everyone to see, we had
> no idea it was there. Even if we had realized it was there, it was
> self-merged 9 hours after it was posted, and it had no gerrit comments
> stating it was experimental.
>
> All Im asking here is that you please inform us about future gerrit
> patches related to this before self-merging them. If the patch isnt
> important, note it as so in the gerrit comment.
>
​Sure​


> Anil, you ask how we do this in SFC, well, we do it like most of the rest
> of the healthy ODL projects: write meaningful gerrit comments and let other
> people review the patch before merging them.
>
​Glad to hear that.

>
> If you with to turn this into a competition to see who gets the last word,
> go ahead, Ive said my peace.
>
​No more words. It's understood.​


>
>
> Regards,
>
> Brady
>
> [0] https://git.opendaylight.org/gerrit/#/c/43305/
>
>
> On 05/10/16 00:32, Sam Hague wrote:
>
>
>
> On Tue, Oct 4, 2016 at 5:38 PM, Anil Vishnoi 
> wrote:
>
>> Hi Brady,
>>
>> Please see inline..
>>
>> On Tue, Oct 4, 2016 at 12:47 PM, Brady Johnson <
>> 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 

Re: [sfc-dev] [netvirt-dev] Networking SFC convertor in ODL

[Brady Allen Johnson]

This discussion isnt really going anywhere.

As you can imagine, its not feasible for us to follow the Netvirt 
Gerrits. Even thought the patch [0] was indeed available for everyone to 
see, we had no idea it was there. Even if we had realized it was there, 
it was self-merged 9 hours after it was posted, and it had no gerrit 
comments stating it was experimental.


All Im asking here is that you please inform us about future gerrit 
patches related to this before self-merging them. If the patch isnt 
important, note it as so in the gerrit comment. Anil, you ask how we do 
this in SFC, well, we do it like most of the rest of the healthy ODL 
projects: write meaningful gerrit comments and let other people review 
the patch before merging them.


If you with to turn this into a competition to see who gets the last 
word, go ahead, Ive said my peace.


Regards,

Brady

[0] https://git.opendaylight.org/gerrit/#/c/43305/ 




On 05/10/16 00:32, Sam Hague wrote:



On Tue, Oct 4, 2016 at 5:38 PM, Anil Vishnoi > wrote:


Hi Brady,

Please see inline..

On Tue, Oct 4, 2016 at 12:47 PM, Brady Johnson
>
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
  

Re: [sfc-dev] [netvirt-dev] Networking SFC convertor in ODL

[Sam Hague]

On Tue, Oct 4, 2016 at 5:38 PM, Anil Vishnoi  wrote:

> Hi Brady,
>
> Please see inline..
>
> On Tue, Oct 4, 2016 at 12:47 PM, Brady Johnson <
> 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/
>> [1] https://git.opendaylight.org/gerrit/#/c/43305/
>>
>>
>> On Tue, Oct 4, 2016 at 8:05 PM, Anil Vishnoi 
>> 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/
>>>
>>> Please see inline...
>>>
>>> On Tue, Oct 4, 2016 at 12:30 AM, Brady Allen Johnson <
>>>