Operating System: All
Platform: All

Downstream consequences:

Merges to integration/testing get -1 from verify job.
Easy fix by Change 29652, with no external consequences.

Merges to integration/distribution get -1 from verify job.
The most prudent fix seem to be removing BGP from integration features (temporarily): https://git.opendaylight.org/gerrit/29470
This would give false positives to external projects which may be affecting this Bug (for example Vpnservice); so if this Bug takes too long to fix, some cross-project testing may be needed before BGP is included in integration again.
Note that Bgpcep test would still install BGP features, as the feature repository stays available.

https://git.opendaylight.org/gerrit/#/c/29660/

> Another alternative is to bump yang-types/ietf-types across the board – not sure how feasible that is.
(source: Robert commenting in https://git.opendaylight.org/gerrit/#/c/29470/)

I tried, not sure if it was worth of the time I spent on it.
Good news: Locally when I build:
Mdsal with https://git.opendaylight.org/gerrit/29692/1
Bgpcep with https://git.opendaylight.org/gerrit/29660/4
Distribution
I get .tar.gz without those Javassist or Augmentation errors.
Bad news:
I had to use -DskipTests as some tests end up in failures.
Restconf returns 401 Unauthorized.
2015-11-14 00:53:32,013 | ERROR | config-pusher | ConfigPusherImpl | 96 - org.opendaylight.controller.config-persister-impl - 0.4.0.SNAPSHOT | Failed to apply configuration snapshot: 31-bgp.xml(odl-bgpcep-bmp,odl-bgpcep-bmp)
java.lang.IllegalStateException: Unable to push configuration due to missing yang models. Required yang models that are missing: [urn:opendaylight:params:xml:ns:yang:controller:bgp:labeled:unicast?module=odl-bgp-labeled-unicast-cfg&revision=2015-05-25]

I do not see an easy way to generate .yang.network.topology.rev131021. classes that would work with both older .yang.ietf.inet.types.rev100924. classes and the newer .yang.ietf.inet.types.rev130715. ones. Aside from just pasting contents of rev130715 yang file into the rev100924 one and keep using that (changes are compatible this way).

I do not expect the long list of project to get their version of Change 29692.

The yang model pasting solution may be the easiest one, followed by removing openconfig stuff from Beryllium Bgpcep.

Do we plan some serious design effort on how to handle multiple revisions and revision bumping in Boron?

> The yang model pasting solution may be the easiest one,
> followed by removing openconfig stuff from Beryllium Bgpcep.

Just to be clear, openconfig removal is a separate solution, not a next step of the first solution.

By the way, we now have new job for system testing multiple patches at once. Change 29692 and Change 29660 fared like this:
https://jenkins.opendaylight.org/sandbox/job/integration-multipatch-test-beryllium/7/

Bgpcep test job failed: https://jenkins.opendaylight.org/sandbox/job/bgpcep-csit-1node-userfeatures-all-beryllium/3/console

2015-11-14 10:20:01,941 | ERROR | config-pusher | ConfigRegistryImpl | 88 - org.opendaylight.controller.config-manager - 0.4.0.SNAPSHOT | Configuration Transaction failed on 2PC, server is unhealthy
java.lang.NoSuchMethodError: org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.TopologyId.<init>(Lorg/opendaylight/yang/gen/v1/urn/ietf/params/xml/ns/yang/ietf/inet/types/rev100924/Uri;)V
at org.opendaylight.ovsdb.southbound.SouthboundConstants.<clinit>(SouthboundConstants.java:46)

My testing suggests this patch by Claudio has no downsides.
Bgpcep master: https://git.opendaylight.org/gerrit/29660/9