[release] Heads up: BUG-1953 being fixed for Helium SR2


Keith Burns <alagalah@...>
 

Dana,

An example ipv6 address you could use for unit testing is here: http://ipv6.com/articles/general/IPv6-Addressing.htm

Currently spending all Thanksgiving break (pun intended) rewriting code due to this regex enforcement. 

Robert, 

I can understand we are finally enforcing correct behavior, but...

May I suggest before we modify and enforce things in root dependency projects we grep code and get sign off from project leads?

Unfortunately I don't have a great answer other than the above, as I don't check some email lists that much due to the poor SNR. 


On Thursday, November 27, 2014, Robert Varga <nite@...> wrote:
java.lang.IllegalArgumentException: Supplied value "1:2:3:4:5:6:7:8:9" does not match any of the permitted patterns [^((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(%[\p{N}\p{L}]+)?$, ^(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(%.+)?$]
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:119)
        at org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev100924.Ipv6Address.<init>(Ipv6Address.java:62)
        at org.opendaylight.openflowjava.protocol.impl.util.OF13MatchSerializerTest.testIpv6Various(OF13MatchSerializerTest.java:165)

That value is definitely not an IPv6 adress :)

Thanks,
Robert

On 11/27/2014 01:19 AM, George Zhao wrote:
Thanks Dana,

I noticed multiple times the auto-release env is not stable, sometime re-trigger the build without any changes will work. Thus when build fail, I normally re-run it immediately manually.

The protocol-framework error just happened to happen two continues build 226 (auto) and 227 (manual) in a row, maybe this issue should be reported to Help desk. That also explains there is no changes seems to related to the error.

In today's scheduled job, the protocol-framework issue was gone, however, the following test failure does not look like an env issue to me. Test failed at Openflow Protocol Library.
https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/228/console



-----Original Message-----
From: Dana Kutenicsova -X (dkutenic - Pantheon Technologies SRO at Cisco) [mailto:dkutenic@...]
Sent: Wednesday, November 26, 2014 12:44 AM
To: George Zhao; Robert Varga; release@...; dev; yangtools-dev@...; dev
Subject: RE: [controller-dev] [release] Heads up: BUG-1953 being fixed for Helium SR2

Hello,
errors with 'could not connect to..' are usually fixed by retriggering the build. Protocol-framework is stable and hasn't been changed over almost a year.
Regards,
Dana
________________________________________
From: controller-dev-bounces@... [controller-dev-bounces@...] on behalf of George Zhao [George.Y.Zhao@...]
Sent: Wednesday, November 26, 2014 4:37 AM
To: Robert Varga; release@...; dev; yangtools-dev@...; dev
Subject: Re: [controller-dev] [release] Heads up: BUG-1953 being fixed for      Helium SR2

The MD-SAL AD-SAL issue was fixed by this patch
https://git.opendaylight.org/gerrit/#/c/13111/.

However, there is a new error in auto-release build, a failure at protocol-framework test.
https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/226/console

I couldn't identify which change caused this error, there are some MD-SAL clustering changes, but I browsed through their changes, it doesn't seem to be related to the failure.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Tuesday, November 25, 2014 12:55 AM
To: George Zhao; release@...; dev; yangtools-dev@...; dev
Subject: Re: [release] Heads up: BUG-1953 being fixed for Helium SR2

Boils down to the prerequisite being on master but not cherry-picked to
stable/helium. Should get fixed with
https://git.opendaylight.org/gerrit/#/c/13111/. Sorry about that.

Bye,
Robert

On 11/25/2014 09:42 AM, Robert Varga wrote:
Interesting, this was supposed to have been fixed. Let me check/submit
a patch.

Bye,
Robert

On 11/25/2014 03:08 AM, George Zhao wrote:
After exam all the changes checked in, most likely auto-release build
failed was introduced by this change:
https://git.opendaylight.org/gerrit/#/c/11319/



-----Original Message-----
From: George Zhao
Sent: Monday, November 24, 2014 5:56 PM
To: 'Robert Varga'; release@...; dev;
yangtools-dev@...; dev
Cc: dev
Subject: RE: [release] Heads up: BUG-1953 being fixed for Helium SR2

Hi

https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/224/console


auto-release failed at MD-SAL to AD-SAL Adaption test, wonder if
someone has more insight of this.

Thanks,

George

-----Original Message-----
From: release-bounces@...
[mailto:release-bounces@...] On Behalf Of Robert
Varga
Sent: Friday, November 21, 2014 8:04 AM
To: release@...; dev;
yangtools-dev@...; dev
Subject: [release] Heads up: BUG-1953 being fixed for Helium SR2

Hello everyone,

this is a heads up that we will be merging the fix for BUG-1953
(https://git.opendaylight.org/gerrit/#/c/11319/) on Monday. This has the
potential to cause compile-time and run-time failures when an attempt is
made to use strings which are non-conformant to the regular expressions
specified in the YANG module. Such attempts will now raise an
IllegalArgumentException.

This instantiates a first-order defense to prevent wrong-use bugs --
like BUG-1772, where obviously-wrong data seems to have entered system
and caused an OpenFlowJava failure.

Thanks,
Robert
_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Robert Varga <nite@...>
 

Hello Keith,

We try to, this particular patch has been on the back-burner for ~2months, not to disrupt ongoing release process.

For this particular fix, it is pretty much impossible to grep for something to flag problems. Unfortunately our infra is only getting to a point where it can do something useful for these 'what-if' scenarios.

Bye,
Robert

On 11/27/2014 02:48 PM, Keith Burns wrote:

Dana,

An example ipv6 address you could use for unit testing is here: http://ipv6.com/articles/general/IPv6-Addressing.htm

Currently spending all Thanksgiving break (pun intended) rewriting code due to this regex enforcement. 

Robert, 

I can understand we are finally enforcing correct behavior, but...

May I suggest before we modify and enforce things in root dependency projects we grep code and get sign off from project leads?

Unfortunately I don't have a great answer other than the above, as I don't check some email lists that much due to the poor SNR. 

On Thursday, November 27, 2014, Robert Varga <nite@...> wrote:
java.lang.IllegalArgumentException: Supplied value "1:2:3:4:5:6:7:8:9" does not match any of the permitted patterns [^((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(%[\p{N}\p{L}]+)?$, ^(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(%.+)?$]
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:119)
        at org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev100924.Ipv6Address.<init>(Ipv6Address.java:62)
        at org.opendaylight.openflowjava.protocol.impl.util.OF13MatchSerializerTest.testIpv6Various(OF13MatchSerializerTest.java:165)

That value is definitely not an IPv6 adress :)

Thanks,
Robert

On 11/27/2014 01:19 AM, George Zhao wrote:
Thanks Dana,

I noticed multiple times the auto-release env is not stable, sometime re-trigger the build without any changes will work. Thus when build fail, I normally re-run it immediately manually.

The protocol-framework error just happened to happen two continues build 226 (auto) and 227 (manual) in a row, maybe this issue should be reported to Help desk. That also explains there is no changes seems to related to the error.

In today's scheduled job, the protocol-framework issue was gone, however, the following test failure does not look like an env issue to me. Test failed at Openflow Protocol Library.
https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/228/console



-----Original Message-----
From: Dana Kutenicsova -X (dkutenic - Pantheon Technologies SRO at Cisco) [mailto:dkutenic@...]
Sent: Wednesday, November 26, 2014 12:44 AM
To: George Zhao; Robert Varga; release@...; dev; yangtools-dev@...; dev
Subject: RE: [controller-dev] [release] Heads up: BUG-1953 being fixed for Helium SR2

Hello,
errors with 'could not connect to..' are usually fixed by retriggering the build. Protocol-framework is stable and hasn't been changed over almost a year.
Regards,
Dana
________________________________________
From: controller-dev-bounces@... [controller-dev-bounces@...] on behalf of George Zhao [George.Y.Zhao@...]
Sent: Wednesday, November 26, 2014 4:37 AM
To: Robert Varga; release@...; dev; yangtools-dev@...; dev
Subject: Re: [controller-dev] [release] Heads up: BUG-1953 being fixed for      Helium SR2

The MD-SAL AD-SAL issue was fixed by this patch
https://git.opendaylight.org/gerrit/#/c/13111/.

However, there is a new error in auto-release build, a failure at protocol-framework test.
https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/226/console

I couldn't identify which change caused this error, there are some MD-SAL clustering changes, but I browsed through their changes, it doesn't seem to be related to the failure.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Tuesday, November 25, 2014 12:55 AM
To: George Zhao; release@...; dev; yangtools-dev@...; dev
Subject: Re: [release] Heads up: BUG-1953 being fixed for Helium SR2

Boils down to the prerequisite being on master but not cherry-picked to
stable/helium. Should get fixed with
https://git.opendaylight.org/gerrit/#/c/13111/. Sorry about that.

Bye,
Robert

On 11/25/2014 09:42 AM, Robert Varga wrote:
Interesting, this was supposed to have been fixed. Let me check/submit
a patch.

Bye,
Robert

On 11/25/2014 03:08 AM, George Zhao wrote:
After exam all the changes checked in, most likely auto-release build
failed was introduced by this change:
https://git.opendaylight.org/gerrit/#/c/11319/



-----Original Message-----
From: George Zhao
Sent: Monday, November 24, 2014 5:56 PM
To: 'Robert Varga'; release@...; dev;
yangtools-dev@...; dev
Cc: dev
Subject: RE: [release] Heads up: BUG-1953 being fixed for Helium SR2

Hi

https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/224/console


auto-release failed at MD-SAL to AD-SAL Adaption test, wonder if
someone has more insight of this.

Thanks,

George

-----Original Message-----
From: release-bounces@...
[mailto:release-bounces@...] On Behalf Of Robert
Varga
Sent: Friday, November 21, 2014 8:04 AM
To: release@...; dev;
yangtools-dev@...; dev
Subject: [release] Heads up: BUG-1953 being fixed for Helium SR2

Hello everyone,

this is a heads up that we will be merging the fix for BUG-1953
(https://git.opendaylight.org/gerrit/#/c/11319/) on Monday. This has the
potential to cause compile-time and run-time failures when an attempt is
made to use strings which are non-conformant to the regular expressions
specified in the YANG module. Such attempts will now raise an
IllegalArgumentException.

This instantiates a first-order defense to prevent wrong-use bugs --
like BUG-1772, where obviously-wrong data seems to have entered system
and caused an OpenFlowJava failure.

Thanks,
Robert
_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev


alagalah <alagalah@...>
 

BTW Robert,

I didn’t mean to sound snarky… facts are facts. You simply fixed something that should have been fixed, my code needs to change to be compliant, like it should have been, so we WERE leveraging a loophole (I guess that’s the best way to put it). 

As I said, I don’t have a great alternative to sending out notification emails to these lists… every other idea I had just seems to suck.


On Nov 27, 2014, at 5:48 AM, Keith Burns <alagalah@...> wrote:

Dana,

An example ipv6 address you could use for unit testing is here: http://ipv6.com/articles/general/IPv6-Addressing.htm

Currently spending all Thanksgiving break (pun intended) rewriting code due to this regex enforcement. 

Robert, 

I can understand we are finally enforcing correct behavior, but...

May I suggest before we modify and enforce things in root dependency projects we grep code and get sign off from project leads?

Unfortunately I don't have a great answer other than the above, as I don't check some email lists that much due to the poor SNR. 

On Thursday, November 27, 2014, Robert Varga <nite@...> wrote:
java.lang.IllegalArgumentException: Supplied value "1:2:3:4:5:6:7:8:9" does not match any of the permitted patterns [^((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(%[\p{N}\p{L}]+)?$, ^(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(%.+)?$]
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:119)
        at org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev100924.Ipv6Address.<init>(Ipv6Address.java:62)
        at org.opendaylight.openflowjava.protocol.impl.util.OF13MatchSerializerTest.testIpv6Various(OF13MatchSerializerTest.java:165)

That value is definitely not an IPv6 adress :)

Thanks,
Robert

On 11/27/2014 01:19 AM, George Zhao wrote:
Thanks Dana,

I noticed multiple times the auto-release env is not stable, sometime re-trigger the build without any changes will work. Thus when build fail, I normally re-run it immediately manually.

The protocol-framework error just happened to happen two continues build 226 (auto) and 227 (manual) in a row, maybe this issue should be reported to Help desk. That also explains there is no changes seems to related to the error.

In today's scheduled job, the protocol-framework issue was gone, however, the following test failure does not look like an env issue to me. Test failed at Openflow Protocol Library.
https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/228/console



-----Original Message-----
From: Dana Kutenicsova -X (dkutenic - Pantheon Technologies SRO at Cisco) [mailto:dkutenic@...]
Sent: Wednesday, November 26, 2014 12:44 AM
To: George Zhao; Robert Varga; release@...; dev; yangtools-dev@...; dev
Subject: RE: [controller-dev] [release] Heads up: BUG-1953 being fixed for Helium SR2

Hello,
errors with 'could not connect to..' are usually fixed by retriggering the build. Protocol-framework is stable and hasn't been changed over almost a year.
Regards,
Dana
________________________________________
From: controller-dev-bounces@... [controller-dev-bounces@...] on behalf of George Zhao [George.Y.Zhao@...]
Sent: Wednesday, November 26, 2014 4:37 AM
To: Robert Varga; release@...; dev; yangtools-dev@...; dev
Subject: Re: [controller-dev] [release] Heads up: BUG-1953 being fixed for      Helium SR2

The MD-SAL AD-SAL issue was fixed by this patch
https://git.opendaylight.org/gerrit/#/c/13111/.

However, there is a new error in auto-release build, a failure at protocol-framework test.
https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/226/console

I couldn't identify which change caused this error, there are some MD-SAL clustering changes, but I browsed through their changes, it doesn't seem to be related to the failure.


-----Original Message-----
From: Robert Varga [mailto:nite@...]
Sent: Tuesday, November 25, 2014 12:55 AM
To: George Zhao; release@...; dev; yangtools-dev@...; dev
Subject: Re: [release] Heads up: BUG-1953 being fixed for Helium SR2

Boils down to the prerequisite being on master but not cherry-picked to
stable/helium. Should get fixed with
https://git.opendaylight.org/gerrit/#/c/13111/. Sorry about that.

Bye,
Robert

On 11/25/2014 09:42 AM, Robert Varga wrote:
Interesting, this was supposed to have been fixed. Let me check/submit
a patch.

Bye,
Robert

On 11/25/2014 03:08 AM, George Zhao wrote:
After exam all the changes checked in, most likely auto-release build
failed was introduced by this change:
https://git.opendaylight.org/gerrit/#/c/11319/



-----Original Message-----
From: George Zhao
Sent: Monday, November 24, 2014 5:56 PM
To: 'Robert Varga'; release@...; dev;
yangtools-dev@...; dev
Cc: dev
Subject: RE: [release] Heads up: BUG-1953 being fixed for Helium SR2

Hi

https://jenkins.opendaylight.org/odlautorelease/job/autorelease-helium-worker/224/console


auto-release failed at MD-SAL to AD-SAL Adaption test, wonder if
someone has more insight of this.

Thanks,

George

-----Original Message-----
From: release-bounces@...
[mailto:release-bounces@...] On Behalf Of Robert
Varga
Sent: Friday, November 21, 2014 8:04 AM
To: release@...; dev;
yangtools-dev@...; dev
Subject: [release] Heads up: BUG-1953 being fixed for Helium SR2

Hello everyone,

this is a heads up that we will be merging the fix for BUG-1953
(https://git.opendaylight.org/gerrit/#/c/11319/) on Monday. This has the
potential to cause compile-time and run-time failures when an attempt is
made to use strings which are non-conformant to the regular expressions
specified in the YANG module. Such attempts will now raise an
IllegalArgumentException.

This instantiates a first-order defense to prevent wrong-use bugs --
like BUG-1772, where obviously-wrong data seems to have entered system
and caused an OpenFlowJava failure.

Thanks,
Robert
_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev