There are patches in ovsdb plugin and openflowplugin pushed afterwards to adapt 
to the change.
So, I am assuming that there was some post TSC discussion to go ahead with the 
change :


https://git.opendaylight.org/gerrit/#/c/71105/
https://git.opendaylight.org/gerrit/#/c/71072/

If so, can we get these patches merged asap?

Thanks,
Faseela


From: Faseela K
Sent: Friday, April 20, 2018 8:01 AM
To: Anil Vishnoi <[email protected]>; Robert Varga <[email protected]>
Cc: [email protected]; 
[email protected]; Release <[email protected]>; 
[email protected]; Tom Pantelis <[email protected]>
Subject: RE: [openflowplugin-dev] Build breakage in openflowplugin due IP 
address NoZone changes

Robert,

Was the revert patch merged? I don’t see it here : 
https://git.opendaylight.org/gerrit/#/q/project:mdsal+branch:master+status:merged


I am hitting one issue in ovsdb plugin in master, where configuration is not 
going through to the switch.  Genius CSITs are failing on master. Wondering 
whether this has an impact.

Thanks,
Faseela

From: 
[email protected]<mailto:[email protected]>
 [mailto:[email protected]] On Behalf Of Anil 
Vishnoi
Sent: Friday, April 20, 2018 3:14 AM
To: Robert Varga <[email protected]<mailto:[email protected]>>
Cc: 
[email protected]<mailto:[email protected]>;
 [email protected]<mailto:[email protected]>; 
Release 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>;
 Tom Pantelis <[email protected]<mailto:[email protected]>>
Subject: Re: [openflowplugin-dev] Build breakage in openflowplugin due IP 
address NoZone changes



On Thu, Apr 19, 2018 at 2:00 PM, Robert Varga <[email protected]<mailto:[email protected]>> 
wrote:
On 19/04/18 21:49, Anil Vishnoi wrote:

Hello Anil,

I am splitting the thread here to focus at the two separate issues at
hand in separate threads. This reply focuses on the use of
ip{v4,v6}-address-no-zone in OFP, e.g. the content of
https://git.opendaylight.org/gerrit/#/c/71083/.
​
Note: My question is not related to OFP, it's related to the derive types 
defined in ietf-type and the way it's implemented in mdsal, so please stop 
referring to OFP on how it's using it. The way currently it's using or for that 
matter other project (Lisp, ovsdb etc) it technically not wrong as per 
ietf-types as well.


> On Thu, Apr 19, 2018 at 11:53 AM, Robert Varga <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>> wrote:
>
>     On 19/04/18 20:22, Anil Vishnoi wrote:
>     >     All of this results in better overall user experience, I think, but 
> that
>     >     is just my opinion.
>     >
>     > ​ Yes, these are good suggestion and OFP project can take these into
>     > account for future enhancement, but why they can't use the existing
>     > thing in the way it is?
>     > Let me drill down to very simple question (to get an answer that i can
>     > understand at my level).
>     >
>     > 
> https://git.opendaylight.org/gerrit/#/c/71083/3/openflowjava/openflow-protocol-spi/src/main/yang/openflow-switch-connection-config.yang
>     
> <https://git.opendaylight.org/gerrit/#/c/71083/3/openflowjava/openflow-protocol-spi/src/main/yang/openflow-switch-connection-config.yang>
>     > ​
>     >
>     >
>     > ​ Why do i need to change ipv4-address to ipv4-addresss-no-zone here in
>     > my yang model? Given that both of these are very valid derive type
>     > defined in ietf-types.
>
>     The answer to this question is modeling exercise. Does a zone make sense
>     in this context?
>
> ​Lets assume it does, why do mdsal code generate care about it?​

It does not, full stop.
​None of MDSAL concern, they are using the valid derive type, may not be 
optimal, but it's NOT wrong.

The patch I proposed is my modeling proposal, nothing more, nothing
less. There are definitely places in bgpcep which will switch to the
no-zone types, I thought it might be useful to OFP.

As I explained, it will simplify and speed things up in OFP because of
the guarantees MD-SAL can give you when you switch to no-zone types. I
think if you review the patch and the scenery of the files it touches,
there is quite a bit of code which could be cut out, most of it in
critical fast paths. This patch does not do that, as it is a minimal
conversion.
​As i said please move your focus from OFP. Assume it's a simple application 
that was using ipv4-address and they still want to use it.​

​So how do we solve this problem now?​

It is up to you if you take it at face value. I have abandoned the patch
-- feel free to resurrect it, but I will not be driving it forward.
MD-SAL does not care and I don't love OFP enough to spend my personal
time on it beyond what I have already contributed.
​Sure, make sense. But even if you don't love OFP, please don't break it ;)​


Regards,
Robert



--
Thanks
Anil
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to