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]] On Behalf Of Anil Vishnoi Sent: Friday, April 20, 2018 3:14 AM To: 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 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
