Hey Luis, not sure which errors/exceptions you are referring to. Got any pointers? Thanks, Robert

Hi Luis, thanks for the link. Quick review ... - the initial warnings are obviously from the container startup, not harmful - InterruptedExceptions -- I think Michal Rehak was working around that (if

I have to claim ignorance here. Do we have a framework for testing component activation using ADM? Thanks, Robert

Hello committers, can you merge https://git.opendaylight.org/gerrit/#/c/9239/ as soon as possible? Without that patch SP edition is broken. Bye, Robert

Actually RFC6020 defines the evaluation order, so this should get eliminated as an enhancement. Not sure if we have one -- can you check/file one? Thanks, Robert

Hello Luis, Your test vectors are not consistent with the model (opendaylight-match-types.yang), specifically you are using a plain IPv4 address where an ipv4-prefix is required. Either the test vecto

Hello Chris, Unfortunately that is not the case -- the datastore performs structural validation, but it does not check leaf values and leafref validity. That capability is coming in Lithium (BUG-2362)

Actually, I think this would be better solved by staging the artifacts for the downstream build(s), which quickly brings you to managing a continuous delivery pipeline -- this sort of validation is a

The merge and integration have been made mutually exclusive, or what happens if the two publish artifacts at the same time? Also, this means that integration jobs must trigger downstream integration j

Okay, but that means the system is broken, as the integration jobs are supposed to guard the published artifacts -- which used to be published *only* by merges, but that is no longer true. Right, we d

Hi, fuzz testing is great. One problem we currently have from implementation perspective is that we do not perform full value/reference integrity checking in the NB layers. We should be in a much bett

I must have missed the reply... what does "almost never" mean? As far as I know the deployment to nexus is not atomic, which means that the versions automatically appended by nexus (timestamps?) may g

The problem was triggered by a change to org/opendaylight/lispflowmapping/mappingservice.yangmodel/1.2.0-SNAPSHOT/mappingservice.yangmodel-1.2.0-SNAPSHOT.pom, which points to yangtools/binding-parent

The patch series to achieve the equivalent (and more) has been posted almost two weeks ago: https://git.opendaylight.org/gerrit/#/c/13258 (needs to get the 'submit' button pressed only) https://git.op

Hello, I am not sure I follow what exactly is the plan here. Is there going to be a centralized 'this is what integration looks like' job? Furthermore how does this interact with the ${project}-integr

So the problem I see is the following: 1) a controller committer merges a patch 2) controller-merge-master publishes artifacts 3a) controller-distribution triggers 3b) openflowjava-integration-master

Yeah, but the point is that anything that uses that distribution may end up with an inconsistent image, so you may end up with various false positives. And those will be transient and nigh-impossible

Note that I am not questioning the intent, but am worried about the results as-currently-implemented. It is very important to understand what artifacts will get into that distribution, since if that i

Hello Luis, ... and this is wrong, as shown by the way the jobs behaved when we changed guava version. I ended up re-merging the last odlparent change about 4 times just to trigger integration jobs, w

I seem to remember some issues with how it accounted for the various things we send out irrespective of what is happening, like statistics collection. I may wrong, though. Again, from memory, I think