Jump to: navigation, search


This content is out-of-date and is considered deprecated. It is unlikely to be updated in the future either. Information here should be taken with that in mind.

The current Weather page is deprecated in favor of raising Weather-type Jiras

According to https://lists.opendaylight.org/pipermail/release/2018-April/014848.html, we now use the "TSC" JIRA project instead of this Wiki page to track Weather items.

This page exists to track current and past issues that may concern multiple projects. The idea is to report anything that you are doing that might break other projects and/or report breakages that are coming from other projects. Then, people can look here to see if one of the current issues explains the breakage they're seeing and help them fix it.

In general, there are two reasons you're posting here.

  1. You're going to make a change that might break people.
  2. You've just had something break on you that appears to be caused by some other project and it's not already listed here.

In either event copy the example issue to current weather report and fill it out to the best of your ability. Then send a mail to the release list as well as relevant project dev lists if you know them with a link to the relevant section on this page. Make sure the subject starts with [WEATHER].


Weather Item Template

Example Issue

  • Description: Short description of the weather item.
  • Reported By: <name>, Email: <email>, IRC: <IRC Handle>, ID:<ODL User ID>
  • Reported On: <date:time>
  • Link to e-mail reporting it: <Mailing List URL Link>
  • Links to opened bugs:
    • [link-to-bug-one-in-bugzilla description of bug 1]
    • [link-to-bug-two-in-bugzilla description of bug 2]
  • Links to patches:
    • [link-to-patch-one-in-gerrit description of patch 1]
    • [link-to-patch-two-in-gerrit description of patch 2]
  • Expected date patches will be merged:
  • Example output showing the error:
Put your logs
Spanning lines
  • Steps to Reproduce:
  1. step one
  2. step two
  • Proposed Solution: <description goes here>
  • Proposed Workaround: <description goes here>

Blocker Bugs

Blocker Bugs Definition

Blocking bugs may meet one or more of the following conditions:

  • Cause a major controller-wide regression. e.g: A bug in openflowplugin prevents OpenFlow switches from connecting.
  • Cause a major regression in another project. e.g: A bug in OVSDB causes GBP service to fail.
  • Dramatically decrease controller performance or scale. e.g: A bug in yangtools causes OpenFlow perf test results to decrease by an order of magnitude.
  • Are immediately obvious to users. e.g: A bug in DLUX makes topology unavailable in the GUI.

Generally, major regressions are likely candidates. Of course, terms like "major" require substantial case-by-case interpretation.

Boron Blocker Bugs


Carbon Blocker Bugs


Nitrogen Blocker Bugs


Current Weather Report

New service index for COE Kube Proxy in Genius

  • Description:

COE requires a new service for handling the kube proxy implementation, the service needs to be of higher priority than L3. Currently all service indices above L3 are fully occupied, and hence, to accomodate this new requirement all services from L3 and below need to increment their service index by 1. Creating this weather item to get a consent from all applications on this change of service priority.

The Kubernetes network proxy runs on each node. This reflects services as defined in the Kubernetes API on each node and can do simple TCP and UDP stream forwarding or round robin TCP and UDP forwarding across a set of backends. Multiple pods can be behind a service IP, and the proxy decides which backend to forward the traffic to. COE is planning to have an implementation of this kube proxy service, where each node will run a local Kube Proxy, and programs the new table to(180) with flow rules with load balancing decision. We are not using openflow based load balancing, however the load balancer sits outside ODL, and just feeds the results of the load-balancing to the OVS through openflow.

SingleTransactionDataBroker with RetryingManagedNewTransactionRunner

  • Description:

The SingleTransactionDataBroker is a genius utility used in genius itself, netvirt, and by indirection any code calling any of genius & netvirt APIs. In order to solve OptimisticLockFailedException I propose that SingleTransactionDataBroker gets built-in retries. Vivek S. has pointed out that in theory, this could interfere with applications who have their own retry logic. We thus want all genius downstream projects to be aware of this change as merge it.

Remove mechanism for mounting netconf devices via the config system in Nitrogen

  • Description:

With the introduction of the new mechanism to configure netconf connectors through the config datastore in Beryllium, the mechanism of mounting via the config system is no longer needed. It was officially deprecated in Carbon via the Release Notes and further stated removal was slated for Nitrogen. Also Netconf Examples was updated a while ago to warn users that it is deprecated and to point users to the new mechanism. Therefore the config system mounting mechanism is being removed in Nitrogen.

OpenFlowJava being merged into OpenFlowPlugin in Nitrogen

  • Description:

Merge OpenFlowJava into OpenFlowPlugin repository to decrease the logistics related to the OpenFlow southbound development.

Openflowplugin He-design is being removed in Nitrogen

  • Description:

Already in Beryllium was Li-design set as default. We announced that He-design is deprecated.

Schema node identifiers MUST always explicitly include the implicit case node identifiers

  • Description:

According to the RFC 7950 section 7.9.2. if a “case” statement is omitted (i.e. “case” shorthand) and implicit “case” node is created, schema node identifiers MUST always explicitly include the implicit “case” node identifiers. Although RFC 6020 is not so clear as RFC 7950 about this, it has been confirmed by Martin Bjorklund in netmod mailing list that this works the same way in both YANG 1 and 1.1. So yang parser will require that all schema node identifiers always explicitly include the implicit case node identifiers. Please see Bug 6183 for more info.

odlparent maven-enforcer-plugin to forbid use of mockito-all

Build failure due to odlparent maven-enforcer-plugin with message "Please always use mockito-core instead of mockito-all"
  • Proposed Solution: Any projects which re-introduced mockito-all since the clean up done for all of them would just have to re-replace their dependency to mockito-all by mockito-core. However as of autorelease rev. 05e60fe2469569912b64966c1da21b8dd9174e1f we're all good, so this be should be safe and non-disruptive.

Neutron Northbound: Yang Model changes(UUID/TenantID consolidation)

  • Description:

UUID and tenant-id was duplicated in many Yang model. Those two fields were consolidated in a new grouping in common attributes called 'grouping id-attributes'. This changes causes changes to L3, L2-gateway, LBASSv2, metering, Qos and secgroups yang models.

Neutron Northbound: Yang Model changes for Carbon

  • Description:

For Carbon release 3 changes are being done to Neutron Northbound Yang models

  • 1) For yang model in neutron northbound, status field (for example port status) should be in operational, not configuration datastore.

This is as per discussion on this thread: https://lists.opendaylight.org/pipermail/netvirt-dev/2017-February/003141.html

  • 2) Project id field is going to depreciate tenant id. More information can be found in following report


Detection of identifier collisions according to RFC 6020 / RFC 7950

  • Description:

Currently, Yang parser does detection of identifier (i.e. name) collisions for data schema nodes (i.e. leafs, containers, lists, etc.). However, the following patch https://git.opendaylight.org/gerrit/#/c/51400/ extends current detection of identifier collisions also for RPCs, Notifications, Actions and Cases etc., according to the RFC 6020 / RFC 7950 (Section 6.2.1): "All leafs, leaf-lists, lists, containers, choices, rpcs, actions, notifications, anydatas, and anyxmls defined (directly or through a "uses" statement) within a parent node or at the top level of the module or its submodules share the same identifier namespace...." . Yangtools distribution check job (https://jenkins.opendaylight.org/releng/job/yangtools-distribution-check-carbon/1443/) reveals the following issues:


However, there could exist more issues in other projects, so please try to test it with this patch. Thanks.

Yangtools: Change of if-feature related API

  • Description:

If-feature argument may be a boolean expression over feature names since Yang 1.1. In this expression, a feature name evaluates to "true" if and only if the feature is supported by the server. There is a pending patch in the yangtools project which changes API of Yang Statement Parser, SchemaContextFactory, IfFeatureStatement and other if-feature related API. For more details please see the following patch https://git.opendaylight.org/gerrit/#/c/49714/.

Extended SingleFeatureTest incl. TestBundleDiag

Rename some odl-dlux-* features to odl-dluxapps-*

  • Description:

Due to Dlux project split, we are moving all applications to new project called DluxApps. In new project, features have new names (odl-dluxapps-*) and old ones will not be accessible. We tried to create "symlinks", but we will make circular dependency between Dlux and DluxApps projects.

Instead, I renamed all odl-dlux-* features (except odl-dlux-core, which will be the only feature in Dlux) in downstream projects. I also replaced YangUI app with Yangman. YangUI will be deprecated, Yangman is redesigned and more user friendly replacement.

We also removed Topology application from odl-dlux-core featurewhich was used as a landing page, when DLUX was started. So we had to change all projects with their own GUIs and put there default route to those GUIs.

Patches order

  1. Review and merge of non Dlux patches
  2. Disable build of all applications in Dlux project
  3. Clean Dlux project of moved sources - TODO, shouldn't have impact on other projects

Change in yangtools's DataTreeConfiguration

  • Description:

There is a pending patch in the yangtools project which changes the implementation of DataTreeConfiguration. The default data tree configuration for operational data tree now enforces validation of mandatory nodes. If you do not want this validation to be enforced, you will have to create a DataTreeConfiguration object manually using the nested class Builder in the DataTreeConfiguration class.

Change in yangtools's RpcStatement

  • Description:

There is a pending patch in the yangtools project which changes the implementation of RpcStatement. Empty input and output statements are now automatically added to every rpc statement that does not define them.

Change in yangtools's yang-model-api

  • Description:

Interface DocumentedNode has now a nested interface called WithStatus which extends the DocumentedNode. Method getStatus() was moved from the DocumentedNode into the WithStatus interface.

YANG Parser stricter parsing

  • Description: YANG Parser's tolerance to source-level errors is lowered
  • Reported By: Robert Varga, Email: nite@hq.sk, IRC: rovarga, ID:rovarga
  • Reported On: Nov 12 2016
  • Links to opened bugs:
  • Links to patches:
  • Expected date patches will be merged: Nov 15 2016

Change of topology_id in openflow-plugin

Fix of mandatory nodes augmentation to target in another module

  • Description:

Yang parser allows to add mandatory nodes to target node in another module via augmentations in some cases (see unit tests in the patch). This patch fixes this according to the rules defined in RFC6020 (https://tools.ietf.org/html/rfc6020#section-3.1, https://tools.ietf.org/html/rfc6020#section-7.15).

Upgrade to Karaf 4

  • Description:

Karaf 4 brings a number of interesting features for us; this is a blocker for Carbon.

  • Reported By: Stephen Kitt, skitt@redhat.com, IRC handle: skitt, ODLID: skitt
  • Tracking bug: #4129
  • Links to patches: see the tracking bug and its blockers

Downgrade to org.json 20090211

  • Description:

org.json's license includes the controversial "do no evil" requirement, which is considered non-free by Debian, the GNU project, Fedora, Google and Red Hat amongst others. To fix this we need to either replace org.json with other, appropriately-licensed libraries, or downgrade to org.json 20090211 which doesn't have the "do no evil" clause and which can be replaced by Google's clean-room re-implementation. This downgrade brings with it a change to JSONException which is now a checked exception, so code using various JSON methods (including JSONObject's constructor) needs to handle JSONException explicitly.

Restconf Draft11 upgrade and code clean-up

Jersey & JAX-RS Upgrade

  • Description:

A major version upgrade for Jersey and JAX-RS which resolves several bugs in netconf and AAA.

The first attempt of this was reverted and is now slated for the Boron release.

Patches have been formed for netconf and AAA: https://git.opendaylight.org/gerrit/#/c/27397/ https://git.opendaylight.org/gerrit/#/c/27584/ May affect downstream consumers of odl-restconf, odl-restconf-noauth and odl-aaa-authn. Currently these changes are being tested against autorelease prior to merge.

Genius ActionInfo/InstructionInfo/MatchInfo clean-up

  • Description:

The Genius ActionInfo/InstructionInfo/MatchInfo classes have been reworked to avoid using untyped tables of Strings or numbers. The dependents have been updated or are being updated, and as a result we will be removing the deprecated classes within a single cycle (there are no other external users).

Genius AbstractDataChangeListener clean-up

  • Description:

With the deprecation of DCNs, we still see a lot of references to some of the DCN related abstract classes in netvirt as well as in GENIUS. We are planning to remove this Abstract class as the final step of cleaning up of all DCN references in Genius. The classes that will be removed are : AsyncDataChangeListenerBase, AsyncDataChangeListenerBase, ChainableDataChangeListener, ChainableDataChangeListenerImpl, AbstractDataChangeListener

OpenFlowPlugin - Turn Single Layer Serialization on by default

Future Weather Report

List below forecast for any weather item with no set time schedule but is planned for future.

Neutron Northbound: rename tenant-id to project-id

  • Description:

Rename tenant-id member to project-id in yang model As openstack neutron supports keystone v3 and is deprecating keystone v2, tenant-id is renamed to project-id.So will ODL Neutron Northbound. https://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html

As migration, this rename will be done as two steps.

  1. add project-id into related yang models and related java structures. Both tenant-id and project-id will be populated with same value (except format).
  2. remove tenant-id

With the first step, no breakage is expected. The first step will be done in Carbon cycle. With the second step, dependent project that still uses tenant-id will break. The fix will mechanical to use project-id instead of tenant-id. The schedule for the removal step isn't determined yet. At least Nitrogen or Oxygen cycle to follow ODL deprecation process.

  • Reported By: Isaku Yamahata, Email: isaku.yamahata@gmail.com, IRC: yamahata, ID:yamahata
  • Reported On: Dec 7, 2016
  • Link to e-mail reporting it: N/A
  • Links to opened bugs: N/A
  • Links to patches: N/A
  • Expected date patches will be merged: schedule isn't determined yet. Plan is in Nitrogen or Oxygen
  • Example output showing the error: N/A
  • Steps to Reproduce: N/A
  • Proposed Solution: use project-id instead of tenant-id
  • Proposed Workaround: N/A

Climate Weather Report

Open weather items with no active developers and no active investigation.

Neutron Northbound must be loaded before any other JAXB feature

  • Description: Note that this is a long-known issue and thus is closer to climate than weather.
  • Reported By:
    • Ed Warnicke, hagbard@gmail.com, IRC handle: edwarnicke, ODLID:<ODL-username>
    • Ryan Moats, rmoats@us.ibm.com, IRC handle: regXboi, ODLID:<ODL-username>
  • Link to e-mail reporting it: discussed as item 2 in 4/8/15 Lithium Weekly IRC sync
  • Steps to Reproduce:
  1. Load the restconf feature
  2. Load the neutron feature
  3. The Neutron feature won't receive requests
  • Proposed Workaround: Load the neutron feature first.

Historical Weather Report

Removal of genius DataStoreJobCoordinator

  • Description:

we are about to finally really remove the long ago @deprecated DataStoreJobCoordinator utility in genius - as you all know, its reincarnation as JobCoordinator in infrautils is what we use instead now. All known current existing usages of DataStoreJobCoordinator in genius and netvirt have now been removed on master, and I've just done a grep in autorelease and found no other projects using it. Therefore, I'll propose to ASAP merge Tom's https://git.opendaylight.org/gerrit/#/c/66064/ in tomorrow's genius weekly meeting. Any pending in-flight open Gerrits for master in genius and netvirt which for some reason thought they could still use the DataStoreJobCoordinator instead of the JobCoordinator would get broken by this, of course; they would have to adapt.

Make distribution-check more strict

Current set of verify-like jobs are still allowing at least two multi-project breakage scenarios to happen. One scenario is when an ODL project stops building a snapshot artifact, but a downstream ODL project is still using it. After three weeks the old snapshots are deleted from Nexus, and the downstream project breaks. The other scenario is when one ODL project does not write a (Config Subsystem) configfile dependency to its features pom file. While builds of this project still pass, a downstream ODL project (if depending on the feature) starts failing their SingleFeatureTest. Both cases are much worse if the artifact/feature is in distribution, because in that case distribution-check jobs start failing for everyone. Even when not in distribution, both scenarios break autorelease. To avoid both scenarios, a Change is contributed. It makes distribution-check emulate inter-project interaction via Nexus. While the Change was tested on several projects, there may be unexpected failures.

Change was reviewed and approved by RelEng/Builder committers and it will be merged Monday 2017-01-23. No actions are required from projects. It is recommended for committers to recheck open changes after the Change is merged. Anyone can test their {project}-distribution-check-{stream} job (against head or any open change) on Sandbox beforehand, to minimize risk.

Upgrade to Karaf 3.0.x

  • Description:

We'd like to benefit from upgrades and bug-fixes to Karaf's 3.0.x series, but these upgrades can cause issues.

target-ide/ instead of target/ as output folder under M2E in Eclipse

Distribution Size

Beryllium Blocking Bugs


Minor change of BitsTypeDefinition and EnumTypeDefinition API in Yangtools

  • Description:

There have been the following minor changes in BitsTypeDefinition and EnumTypeDefinition API in Yangtools: - getPosition() and getValue() cannot be null and therefore they return simple types now (i.e. int and long instead of Integer and Long).

Change of yang-model-api in yangtools

  • Description:

There has been a change in yang-model-api in Yangtools. The DataNodeContainer's method getDataChildByName(String) was removed and its users should now use getDataChildByName(QName).

Added return code 201 for PUT method in RESTconf

Table features off by default

Java Binding codebase movement

  • Description:

Java Binding codebase along with prebuilt models is migrated to MD-SAL projects, migration patches are provided to all affected projects.

Majority of projects already accepted incoming patches. https://git.opendaylight.org/gerrit/#/q/topic:be/migration/mdsal+status:open lists outstanding patches to projects. If project is affected, there is outstanding patch for them. Projects which did not merge their patches yet should be UNAFFECTED, since removed yangtools artefacts will be still present in Nexus repository.

Code existing in two places causes confusion for contributors and migration is needed in order to unblock code.

Karaf-parent upgraded to use karaf-plugin

  • Description: Karaf-parent is used by most project local karaf distributions. It has been using the maven dependency hack from Helium to populate system. This was intended to allow 'offline' mode. But this is buggy at best. In Lithium, karaf-parent was introduced, and has been used by integration/distribution since Lithium. We are now migrating to having karaf-parent use karaf-plugin. This *should* simply produce much much faster startup time, and correct offline operation. Because of the pervasive nature of the change, there is some probability of breakage. This change affects projects which produce their own karaf distribution or projects which use opendaylight-karaf-empty for their integration testing. Note that SingleFeatureTest uses pax-exam-container-karaf which is not affected by this change. Integration/Distribution is currently not affected, but may become affected when migrated to karaf-parent.
  • Reported By: Ed Warnicke, hagbard@gmail.com, IRC handle: edwaricke, ODLID:eaw
  • Reported On: Feb 29, 2016
  • Link to e-mail reporting it: https://lists.opendaylight.org/pipermail/discuss/2016-February/006211.html
  • Links to patches:
  • Expected date patches will be merged: TBD, 2016

Blueprint support

  • Description:

The controller core (ie md-sal) now has support for using OSGi blueprint for code wiring. The main motivation for this is for better upgrade support and usability wrt to the config system (CSS). The md-sal services are provided via blueprint (as OSGi services) and also via the CSS. So apps should continue work as is using the CSS. The core blueprint support enables apps to use blueprint for code wiring in lieu of the CSS.

Change of deviation statement API in yangtools

  • Description:

There have been some changes in deviation statement API in project yangtools. A new interface called DeviateDefinition was introduced. It describes yang deviate statement. Method getDeviate() in Deviation interface was replaced by getDeviates() which returns a List of DeviateDefinition(s). The enum Deviation.Deviate was replaced by the enum DeviateKind. DeviateDefinition contains the method getDeviateType() which returns an enum constant from DeviateKind. If you have been using this functionality, please change it according to the description above.


Move of karaf-parent from controller to odlparent

  • Description: Ryan Goulding will move the karaf-parent artifact from controller to odlparent. In the interim, the controller karaf-parent will be reparented to the odlparent version, which will minimize if not eliminate breakage. In Carbon, the controller karaf-parent artifact will be removed.
  • Reported By: Ryan D Goulding <ryandgoulding@gmail.com>
  • Reported On: August 16, 2016
  • Link to e-mail reporting it: email
  • Tracking Spreadsheet: Not really needed for this since it is backwards compatible.

NetVirt VPNService Migration

Removal of YangParserImpl

Nexus URL requires HTTPS

  • Description: After latest Nexus migration change we recommend projects to use the https (secure) URL to access Nexus. The risk of not doing this is some failures may occur when downloading/uploading artifacts from/to Nexus that can yield in a build failure (merge jobs are more impacted). For this reason we ask projects to go through their active branches (e.g. stable/lithium, stable/beryllium, master) and:
  • Reported By: Thanh Ha (thanh.ha@linuxfoundation.org) and Luis Gomez (ecelgp@gmail.com)
  • Reported On: Apr 20, 2016

TCPMD5 migration to netty-native-trasport-epoll

Unmerged Patch for projects to test OpenFlow Plugin default design to Lithium

We need all the dependent projects of OpenFlow Plugin (OFP) to move to the Lithium design for the Boron release. To help in this process OpenFlow Plugin has created an unmerged patch which swaps the default design to the ​new ​Lithium design. The patch is: https://git.opendaylight.org/gerrit/#/c/35892. The purpose of this patch is for projects to identify issues in the migration and help OpenFlow Plugin fix them.

To use this patch projects should:

  • clone the openflowplugin and then checkout this patch it locally​ and build
  • ​​t​est​ ​their project with the locally swapped new plugin

We would like this activity to identify issues to conclude in the next 2 weeks or so (say March 24 - which happens to be the current offset 2 projects M1 date in the provisional traditional release plan ). That way OpenFlow Plugin can factor the gaps needed to fix in the OpenFlow Plugin release plan which is due by M2 for us (current date in the provisional traditional release plan for OFP is April 21). The OFP target for fixing the issues and actually changing the default plugin would likely be either OFP M2 or M3 - depending on the complexity of the issues identified. The issues which cannot be worked around ​and blocking development of the project ​should be raised as blocker issues on OpenFlow Plugin.

Upgrade ietf-{inet,yang}-types to 2013-07-15

distribution-karaf to inherit from karaf-parent

  • Description: Controller project provides karaf-parent pom file, which is used by several projects for a simple creation of customized Karaf container. But Integration/Distribution, as a project providing the official Karaf package for ODL distribution, was not using karaf-parent up to now, which has lead to code duplication. Now there is a Change ready for testing. The change does not require karaf-parent to use karaf-plugin (but that would allow further simplification). Because of the pervasive nature of the change, there is some probability of breakage, so please test your functionality. Note that no ODL project currently depends on integration/distribution/distribution-karaf, so the possible breakage should be limited to CSIT tests and other downstream usage of .zip files.
  • Reported By: Vratko Polak, vrpolak@cisco.com, IRC handle: vrpolak, ODLID:vrpolak
  • Reported On: Jun 08, 2016
  • Link to e-mail reporting it: https://lists.opendaylight.org/pipermail/integration-dev/2016-June/007042.html
  • Links to patches:
  • Expected date patches will be merged: Jun 22, 2016

Neutron Northbound: neutron yang model revise and I*Aware(AD-SAL) interface removal

as of June 23, 2016 all the related patches were merged and breakages were unbroken. So move this item to historical data.

Bug 4527 Security Groups : For "Other Protocol" rule, NeutronSecurityRule.getSecurityRuleProtocol() is set to NULL

2015-11-13 Removal of adsal features dependencies from controller DependencyManagement

Please me very certain to check in with vtn-dev prior to merging the patch to make sure they have in fact met their intention of removing ADSAL artifacts by 11/12/15.

sal-common artifact being removed

  • Description: sal-common, which has been unused since Hydrogen is being removed. It should remain in nexus, and thus not produce breakage, but all projects *should* remove the dependency from their pom.xml files.
  • Reported By: Ed Warnicke, eaw@cisco.com, IRC handle: edwarnicke, ODLID:eaw
  • Link to e-mail reporting it:
  • Links to opened bugs:
  • Links to patches:
  • Example output showing the error:
Put your logs
Spanning lines
  • Steps to Reproduce:
  1. step one
  2. step two
  • Proposed Solution: <description goes here>
  • Proposed Workaround: <description goes here>

Lithium Blocking Bugs


BUG-4295: Lazy Data Tree MERGE operations

  • Description:

Unlike other operations on Data Tree, MERGE operations are currently being eagerly expanded into operations on individual nodes. This leads to sub-optimal performance as well as metadata fragmentation when data is introduced via NETCONF's merge.

Bug 4355 - Data Tree: Enforce 'mandatory true' leaf presence in CONFIG datastore

  • Description:

The DataTree component which is used internally by the clustered data store will be enhanced to validate presence of "mandatory true" statement for configuration data.

01/07/2016 (happened on 2016/01/08)

BUG-1014: enforce config=false nodes not beign present in CONFIG datastore

  • Description:

The DataTree component which is used internally by the clustered data store supports validating whether a particular node belongs to a particular data store instance (configuration or operational) based on its 'config' statement (explicit or implicit). Clustered data store does not pass the required information down, so config data store is instantiated as operational. This weather event is for the CDS starting to pass down that information down. This will result in the data store to reject config=false data in the the configuration data store.

2015/12/08 (happened on 2015/12/15)

BUG-4638: Cleanup TypeDefinition implemenetation

  • Description:

yang-model-util implementation of TypeDefinition interfaces presents inconsistent structure, which is confusing for users of yang-model-api and requires recursive searches in the type tree to acquire the actual node semantics. This is further complicated by implementation classes being public, which leads to confusion between StringTypeDefinition (interface) and StringType (implementation) -- which causes a lot of places to check for implementation instead of interface. The end effect is that a few cases are handled in a consistent manner, which unfortunately does not match current expectations of the Java Binding generator.

BUG-4322: YANG 'default' statements is not being enforced

  • Description:

DataObject instances not instantiated from the applications via the Java DTO builders return the default value as defined by the YANG model when no data is present instead of null.

BUG-2399: Implementation of RFC6020 structural container lifecycle

  • Description:

The implementation of automatic creation and deletion of structural containers, as defined in RFC6020 is being merged into yangtools. This patch removes the need to use of createParents=true in most cases, e.g. where only parents created this way are structural containers. The change also means that empty structural containers will be removed (disappear from RESTCONF) when they are empty. As described in the bugzilla issue, this should be fine, as such containers do not have any semantic meaning. In case such a container is needed (and hence has a meaning), it needs to be marked as 'presence' in the corresponding YANG model, which will cause it to behave the same way as containers have behaved so far.

2015-09-29 YANG Parser implementation switch

  • Description: YANGTools, MD-SAL and Controller project switches implementation of YANG Parser from legacy one (original parser developed in Hydrogen and Helium) for Extensible YANG Parser (developed in Lithium and Beryllium),we did hard to test and fix all issues in new parser, but some hiccups / small problems may occur.

NETCONF / RESTCONF code base being removed


Majority of projects already accepted incoming patches https://git.opendaylight.org/gerrit/#/q/topic:netconf-migration+status:open which migrates projects. If project is affected, there is outstanding patch for them. Projects which did not merge their patches yet should be UNAFFECTED, since removed controller features will be still present in Nexus repository.

Code existing in two places causes confusion for contributors and migration is needed in order to unblock code.

Netconf Restconf Pending Affected Project Gerrit Patches

  1. DLUX: https://git.opendaylight.org/gerrit/#/c/26468/ DONE
  2. L2SWITCH: https://git.opendaylight.org/gerrit/#/c/26529/ DONE
  3. ALTO: https://git.opendaylight.org/gerrit/#/c/26465/ DONE
  4. SNBI: https://git.opendaylight.org/gerrit/#/c/26233/ DONE
  5. NEMO: https://git.opendaylight.org/gerrit/#/c/26587/ DONE

odl-netconf-mdsal moved to feature-netconf

In your feature/pom.xml, make sure you have a dependency on:


where you define the property


and in your features.xml file, make sure to change the version for odl-netconf-mdsal to ${netconf.version}.

YANGtools enforcing all patterns

  • Description:

The fix for BUG-3051 has went into Lithium YANG tools, potentially causing problems with projects which use non-conforming data in their tests and/or implementation. This may require chnages to downstream code, see here for an example of the fixes involved.

  • Reported By: Robert Varga, rovarga@cisco.com, IRC handle: rovarga, ODLID:rovarga
  • Link to e-mail reporting it:


OpenflowPlugin model issues cause feature installation issues

  • Description: OpenflowPlugin's models are not loaded when started causes the odl-ovsdb-openstack feature to not load it's bundles.
  • Reported By:
    • Sam Hague, shague@redhat.com, IRC handle: shague, ODLID:shague
    • Anil Vishnoi, vishnoianil@gmail.com, IRC handle: vishnoianil, ODLID:vishnoanil
  • Link to e-mail reporting it: https://lists.opendaylight.org/pipermail/release/2015-May/002428.html
  • Links to opened bugs:
  • Links to patches:
    • [link-to-patch-one-in-gerrit description of patch 1]
    • [link-to-patch-two-in-gerrit description of patch 2]
  • Example output showing the error:
015-05-22 07:13:35,534 | WARN  | pool-12-thread-1 | DataObjectCodecContext           | 116 - org.opendaylight.yangtools.binding-data-codec - 0.7.0.SNAPSHOT | 
Failed to load augmentation prototype for GeneratedTransferObject [packageName=org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819, 
name=FlowCapableNode, comment=, annotations=[],
java.lang.ClassNotFoundException: org.opendaylight.yang.gen.v1.urn.opendaylight.flow.inventory.rev130819.FlowCapableNode
  • Steps to Reproduce:
  1. start ovsdb karaf distribution
  2. odl-ovsdb-openstack feature is loaded at bootstrap and exceptions occur
  • Proposed Solution: <description goes here>
  • Proposed Workaround: Failures happen randomly so sometimes restarting fixes the issue.

AD-SAL Removal on master (beryllium) branch

  • Description: Removal AD-SAL and related components which wad deprecated in Lithium
  • Reported By:
    • Tony Tkacik, ttkacik@cisco.com IRC handle: ttkacik, ODLID: ttkacik
  • Links to opened bugs:
  • Links to patches:

This change will not affect bumping, since beryllium numbered AD-SAL SNAPSHOT components are present in Nexus repository, but there will be no release version of this components.

Switch to Lithium Notification Broker

503 - Authentication Service Unavailable

  • Description:

Some projects including integration have seen this error when starting karaf with preloaded features (including odl-restconf), weirdly it is not seen when features are installed from console.

  1. configure preloaded features in karaf etc/org.apache.karaf.features.cfg file
  2. start karaf with bin/karaf
  3. do REST GET http://localhost:8181/restconf/modules and you get 503 - Authentication Service Unavailable
  4. check for Java Exception in karaf console
  • Proposed Solution: Work on fixing the Java Exception
  • Proposed Workaround: Start features with feature:install instead of config file

Karaf 3.0.3 Upgrade


In order to support Java 8 we need to upgrade to Karaf 3.0.3. This transition has some potential to introduce breakage. Effort has been made to try to insure it *doesn't* introduce breakage... but letting folks know just in case.

Scheduled Date

Switchover is scheduled to occur on 2015-04-13 (Monday).

Reported By

Ed Warnicke <hagbard@gmail.com> IRC handle: edwarnicke ODLID: eaw

Email reporting it

Open Bugs


odlparent patch

controller patch


  1. This only expected in retrospect, it only breaks some tests, and from ODL point of view, it is a feature. Previous version of karaf had bin/client command allowing connection without credentials, but on 3.0.3 it leads to cryptic NPE. The solution is to provide credentials to client, for example "sshpass -p karaf ./bin/client -u karaf feature:install odl-restconf". This solution works on the current karaf too. This issue does not affect other scripts in bin/ (karaf, start). Also, test jobs by Integration group do install features by editing bootFeatures, so no change is needed there.
  2. It is possible that local .m2 repos could get into a strange state that result in errors either complaining about missing dependency on feature 'standard' or an NPE from the karaf maven plugin.

The solution is to "rm -rf ~/.m2/repository/org/opendaylight" and build again.

  1. UPDATE: Fixed Currently karaf 3.0.3 is known to have breakage, which should be fixed by:
    1. https://git.opendaylight.org/gerrit/#/c/18402/ <- odlparent
    2. https://git.opendaylight.org/gerrit/#/c/18410/ <- controller
  2. UPDATE: Fixed Karaf 3.0.3 maven plugin reinstalls features recursively, giving the appearance of looping on feature install, bloating logs, and causing long builds.
    1. If you are using karaf-parent, this should be fixed by: https://git.opendaylight.org/gerrit/#/c/18525/
    2. If you are setting the maven plugin version locally, use the 3.0.1 version of the karaf-maven-plugin
  3. Tomcat as startupFeature prevents first run of controller: The AD-SAL Northbound features are still pulling in Tomcat, and that is pulling in wrap:mvn:javax.servlet.jsp/jsp-api/2.1 which apparently has an issue. This should not effect any feature using jetty (neutron, restconf, etc).
  4. Karaf 3.0.3 does not install your feature if compile / runtime dependencies referenced from features.xml were not compile / runtime dependencies of features project. That is bug in your application, since build with Karaf 3.0.1 would not install your feature on fresh machine without internet access. In Karaf 3.0.3 it prevents installation of your feature even if required dependencies are in your local .m2 repository.

Helpful Notes

If you would prefer, rather than building odlparent and controller with these patches and then your stuff to test, you can test your stuff in a pre-built integration build that incorporates the changes.

NEW BUILD from 2015-04-08 with OFP fixes and clustering on by default with karaf 3.0.3

  • Do* check at the karaf console with


to make sure you are running karaf version 3.0.3. Please *do* test your functionality.

For local distributions, you may find it much smoother to migrate to using karaf-parent, rather than maintaining all of the build machinery locally. See the hello-karaf example from coretutorials for an example. You should just need the dependencies on your local feature and possibly to set the <karaf.localFeature> property.

Projects that have tested w/o issues

Clustered Data Store Switch over


Currently the MD-SALs default datastore is the inmemory data store. This change would switch to using by default the clustered datastore, including persistence being on for the config datastore.

Scheduled Date

Switchover is scheduled to occur on 2015-04-06 (Monday).

Reported By

Ed Warnicke <hagbard@gmail.com> IRC handle: edwarnicke ODLID: eaw

Email reporting it

Open Bugs

List any collateral bugs below for breakage:

  1. [link-to-bug-one-in-bugzilla description of bug 1]
  2. [link-to-bug-two-in-bugzilla description of bug 2]


  1. Gerrit 14313 implementing the switch
  2. [link-to-patch-two-in-gerrit description of patch 2]

Expected breakages

  1. BGPCEP's RIB structure rework will be broken by this until Support for DOMDataTreeChangeService lands
  2. Services Function Chaining will be broken indefinitely until Netconf and OVSDB fully define their data persistence behavior.

[2] [3] [4] [5]

Helpful Notes

There is a prebuilt integration build with the clustering patches applied to test with here.

Jenkins and Nexus outage


Upcoming outage of Jenkins and Nexus for storage remanagement.

Scheduled Date

Saturday April 04, 2015 (2015-04-04) @ 10:00 - 11:00 PDT

Reported By

Andrew Grimberg <agrimberg@linuxfoundation.org> IRC handle: tykeal ODLID: agrimberg

Email reporting it

Expected breakages

Jenkins and Nexus will be offline for the storage remanagement. Internal builds will fail. External builds that do not already go through a local Maven repository proxy will fail.

OpenFlow Plugin & OpenFlow Java Bugs Blocking other projects


Put your logs
Spanning lines
  • Steps to Reproduce:
  1. step one
  2. step two
  • Proposed Solution: <description goes here>
  • Proposed Workaround: <description goes here>

Jenkins slave instability


Jenkins has recently been having regular issues with slaves not connecting or disconnecting from the master appropriately. LF is aware of the situation and monitoring it, unfortunately this is a manual monitoring process presently. Should you see weird major queue backups pinging either tykeal or zxiiro in either #opendaylight or #opendaylight-releng can be useful.