Re: [openflowplugin-dev] Build breakage in openflowplugin due IP address NoZone changes

Wed, 18 Apr 2018 10:32:14 -0700

Object.equals() is required to be reflexive. Your statement "this is not correct behavior" is based on your human understanding of the model (most notably reading English text in description), not something automation can infer. Therefore codegen cannot generate an .equals() method, which would be both conforming to the API contract and supporting "correct behavior".

Sent from my BlackBerry - the most secure mobile device - via the Orange Network
Sent: April 18, 2018 7:12 PM
Subject: Re: Build breakage in openflowplugin due IP address NoZone changes

Can you please explain it a bit, i am not sure what do you mean by "inferred from anything machine-readable"?

On Wed, Apr 18, 2018 at 10:07 AM, Robert Varga <[email protected]> wrote:
Unfortunately that cannot be inferred from anything machine-readable, so we have to make do with what we have.

Sent from my BlackBerry - the most secure mobile device - via the Orange Network
Sent: April 18, 2018 6:57 PM



On Wed, Apr 18, 2018 at 9:49 AM, Robert Varga <[email protected]> wrote:
Hello Anil,

No, support is not being removed, but Ipv4Address.equals() is defined in a way which returns false when compared with Ipv4AddressNoZone of the same value IIRC, hence things would break.
​This is not correct behavior in my opinion, because ietf clearly says that user "may" add zone, so the equals should not fail if two ipv4-address (without zone) is compared.​
 

Yes, applications can support zones and conversion from NoZone is cheap, so it is a matter of preference.

Sent from my BlackBerry - the most secure mobile device - via the Orange Network
Sent: April 18, 2018 6:13 PM
Subject: Re: Build breakage in openflowplugin due IP address NoZone changes

Hi Robert,

Please see inline..

On Wed, Apr 18, 2018 at 1:33 AM, Robert Varga <[email protected]> wrote:
On 18/04/18 08:09, D Arunprakash wrote:
> Hello,
>
> The following review in mdsal might have impacted openflowplugin
> functionality.
>
> https://git.opendaylight.org/gerrit/#/c/70769/

Sorry about that.

> https://jenkins.opendaylight.org/releng/job/openflowplugin-maven-verify-fluorine-mvn33-openjdk8/259/console
>
>  
>
> org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev130715.Ipv4Address<Ipv4Address{_value=0.1.2.3}>
> but was:
> org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev130715.Ipv4AddressNoZone<Ipv4Address{_value=0.1.2.3}>
>
> is it new expectation on openflowplugin to change from Ipv4Address to
> Ipv4AddressNoZone ?

There are two aspects to this.

As an interim, the codecs from wire need to be updated to convert
Ipv4AddressNoZone to Ipv4Address, so that equality works as expected and
the breakage is recovered -- https://git.opendaylight.org/gerrit/71072
does that.
​This seems like regression. ietf-type (2013-07-15) supports both the version and this revision seems to be backward compatible. So are you removing the support for ipv4-address type? ​
 

Going forward, though, I believe the openflow models need to be updated
to require ipv4-address-no-zone rather than ipv4-address (and same goes
for ip-address and ipv6-address). This really is the correct thing to do
-- ipv4-address is not really the IPv4 address used in OpenFlow protocol.
​Yeah for flows /groups true, but that does not mean application can't use ipv4_address with zone.​
 

Regards,
Robert




--
Thanks
Anil



--
Thanks
Anil



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

Reply via email to