================================== 2026.03 Chromium Platform Upgrade ================================== This document describes the steps to help users upgrade from Vanadium to Chromium platform. Refer to `Managed Snapshot Integrated (MSI) project `_ upgrade patches for more information and hints for solutions to common problems not explicitly listed here. .. contents:: Contents Preparation ----------- JDK 21 Version ^^^^^^^^^^^^^^ 2026.03 Chromium, requires Java 21, both during compile-time and run-time. Make sure to install JDK 21 corresponding to at least ``openjdk-21.0.8``, and that the ``JAVA_HOME`` environment variable points to the JDK directory. Version Bump ^^^^^^^^^^^^ Before performing platform upgrade, do the following to bump the odlparent versions (for example, `bump-odl-version `_): 1. Update the odlparent version from 14.1.6 to 14.3.1. There should not be any reference to **org.opendaylight.odlparent**, except for 14.3.1. This includes custom ``feature.xml`` templates (``src/main/feature/feature.xml``), the version range should be "[14,15)". .. code-block:: shell bump-odl-version odlparent 14.1.6 14.3.1 2. Update the direct yangtools version references from 14.0.20 to 15.0.2, There should not be any reference to **org.opendaylight.yangtools**, except for 15.0.2. This includes custom ``feature.xml`` templates (``src/main/feature/feature.xml``), the version range should be "[15,16)" instead of "[14,15)". .. code-block:: shell bump-odl-version yangtools 14.0.20 15.0.2 3. Update the MD-SAL version from 15.0.2 to 16.0.3. There should not be any reference to **org.opendaylight.mdsal**, except for 16.0.3. .. code-block:: shell bump-odl-version mdsal 15.0.2 16.0.3 4. Update the Controller version from 12.0.3 to 13.0.2. There should not be any reference to **org.opendaylight.controller**, except for 13.0.2. .. code-block:: shell bump-odl-version controller 12.0.3 13.0.2 5. Update the InfraUtils version from 7.1.9 to 7.1.12. There should not be any reference to **org.opendaylight.infrautils**, except for 7.1.12. .. code-block:: shell bump-odl-version infrautils 7.1.9 7.1.12 6. Update the AAA version from 0.22.3 to 0.23.2. There should not be any reference to **org.opendaylight.aaa**, except for 0.23.2. .. code-block:: shell bump-odl-version aaa 0.22.3 0.23.2 7. Update the NETCONF version from 10.0.2 to 11.0.0. There should not be any reference to **org.opendaylight.netconf**, except for 11.0.0. .. code-block:: shell bump-odl-version netconf 10.0.2 11.0.0 8. Update the IETF version from 1.0.2 to 2.0.2. There should not be any reference to **org.opendaylight.ietf**, except for 2.0.2. .. code-block:: shell bump-odl-version ietf 1.0.2 2.0.2 9. Update the gNMI version from 2.0.0 to 3.0.0. There should not be any reference to **org.opendaylight.gnmi**, except for 3.0.0. .. code-block:: shell bump-odl-version gnmi 2.0.0 3.0.0 Install Dependent Projects ^^^^^^^^^^^^^^^^^^^^^^^^^^ Before performing platform upgrade, users must also install any dependent project. To locally install a dependent project, pull and install the respective `chromium-mri `_ changes for any dependent project. Perform the following steps to save time when locally installing any dependent project: * For quick install: .. code-block:: shell mvn -Pq clean install * If previously installed, go offline and/or use the no-snapshot-update option. .. code-block:: shell mvn -Pq -o -nsu clean install Upgrade the ODL Parent ---------------------- The following sub-section describes how to upgrade to the ODL Parent version 14. Refer to the `ODL Parent Release Notes `_ for more information. Features ^^^^^^^^ Any version range referencing version of ODL Parent must be “[14,15)” for ODL Parent 14. .. code-block:: xml odl-guava ODL Parent Impacts ------------------ None. Just make sure to sync up with odlparent dependencies `as seen here. `_ YANG Tools Impacts ------------------ Remove YangModuleInfoImpl.getInstance(): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Since YANG Tools version 15 the ``getInstance()`` method has been removed and needs to be replaced using ``INSTANCE``. See `YANGTOOLS-1780 `__ for more details. DefaultYangParserFactory does not require YangXPathParser: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Remove this parameter as it is not required. The example of new approach follows: .. code-block:: java final DefaultYangParserFactory defaultYangParserFactory = new DefaultYangParserFactory(); Add YangTextToIRSourceTransformer to ModuleInfoSnapshotResolver and SchemaResourceManager ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Add this parameter into initialization of these classes. For example: .. code-block:: java this.snapshotResolver = new ModuleInfoSnapshotResolver("binding-dom-codec", new DefaultYangTextToIRSourceTransformer(), yangParserFactory); Add yang-xpath-impl and yin-source-dom dependencies if required ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Depending on your implementation, add these dependencies to resolve ``IllegalStateException: No YangXPathParserFactory found`` or ``No YinTextToDOMSourceTransformer found``. This Exception is thrown because ``DefaultYangParserFactory`` uses ``ServiceLoader`` to try to lookup ``YangXPathParserFactory``, and the ``YangXPathParserFactory`` was moved in: `YANGTOOLS-1699 `__ and `YANGTOOLS-1707 `__ .. code-block:: xml org.opendaylight.yangtools yang-xpath-impl .. code-block:: xml org.opendaylight.yangtools yin-source-dom ANTLR Parser and Lexer Refactoring ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The YANG parsing infrastructure has been significantly refactored to prevent leaking ANTLR dependencies to downstream consumers. The original ``yang.parser.antlr`` implementation—which historically handled the YANG grammar, ``if-feature-expr``, and ``path-arg`` with fragmented exception handling—has been cleanly split. See `YANGTOOLS-1707 `__ for more details. * **YANG Lexer API:** The base lexing functionality (which compiles files into an immutable object model without dealing with string un-escaping or ``yang-version`` semantics) is now formally defined by ``parser.spi.YangLexer``. The reference ANTLR-based implementation is provided by the new ``yang-lexer-ri`` artifact. * **Relocated Grammars:** The ``if-feature-expr`` and ``path-arg`` parsing logic has been moved out of the core lexer and relocated to ``yang-parser-rfc7950`` (specifically alongside ``IfFeatureStatementSupport`` and ``PathStatementSupport`` in ``rfc7950-parser-support``), as these are strictly tied to RFC6020/RFC7950 semantics. * **Unified Exception Handling:** The parsing infrastructure now strictly operates on the checked ``yang.parser.api.YangParserException``. This replaces the previous convoluted approach (where the main parser threw ``YangSyntaxErrorException`` and the others threw ``SourceException``). The unified exception natively includes explicit references to the ``SourceIdentifier`` and positional error data (line/row). **Migration Steps:** 1. **Update Dependencies:** If your project directly depended on the old ``yang.parser.antlr`` artifact or explicitly referenced OpenDaylight's ANTLR classes, you must migrate to the new ``parser.spi.YangLexer`` API. Ensure you include the ``yang-lexer-ri`` artifact at runtime. 2. **Update Exception Handling:** Update your ``try-catch`` blocks to catch ``YangParserException`` instead of ``YangSyntaxErrorException`` or ``SourceException`` when interacting with the parser. 3. **Statement Parsing:** If your code explicitly parses ``if-feature`` or ``path`` arguments, ensure your module depends on the correct RFC7950 parser support artifacts, as these are no longer bundled in the base lexer. An example of the refactor can be found in `commit 6597252 `__. Update DatabindContext import ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The ``DatabindContext`` was migrated to ``yangtools`` in `commit 2265500 `__. Just update the import of this class to: .. code-block:: java import org.opendaylight.yangtools.databind.DatabindContext; Split out model.api.meta.BuiltInType ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The constants previously found in ``TypeDefinitions`` have been migrated to the ``BuiltInType`` enumeration. When checking against built-in type QNames, you must now use ``BuiltInType..typeName()``. Additionally, the ``getType()`` method in ``TypedDataSchemaNode`` has been renamed to ``typeDefinition()`` to better align with the overall YANG model API naming conventions. The example of the new approach follows: .. code-block:: java // 1. Getting the type definition from a TypedDataSchemaNode final var dataSchemaType = ((TypedDataSchemaNode) dataSchemaNode).typeDefinition(); // 2. Comparing against built-in types if (qname.equals(BuiltInType.BOOLEAN.typeName())) { return Boolean.valueOf(value); } else if (qname.equals(BuiltInType.UINT32.typeName())) { return Uint32.valueOf(value); } MD-SAL Impacts -------------- None. IETF Liaison Project Impacts ---------------------------- * Please take into account that since Vanadium YANG models related artifacts have been moved from ``MD-SAL`` to the new ``ietf`` project. Update your dependencies accordingly. The new group-id is ``org.opendaylight.ietf``. * See the `project proposal `__. Netconf Impacts --------------- OpenAPI: separate out jaxrs and netty ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This module was separated and depending on your implementation, you might need to add this dependency to use it. .. code-block:: xml org.opendaylight.netconf restconf-openapi-jaxrs For more info, follow: `NETCONF-1605 `__. Change OpenAPI base path handling ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ OpenAPI now gets its base path from a string instead of ``JaxRsEndpoint``, so there is no need to rely on ``JaxRsEndpoint``. For more info, follow: `NETCONF-1560 `__. RESTCONF HTTP/3 Support and NettyEndpointConfiguration Impacts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ RESTCONF now natively supports an HTTP/3 (QUIC) listener. This listener bootstraps automatically when TLS (certificate and private key) and a bind address/port are configured. Because of this addition, the ``NettyEndpointConfiguration`` class constructors have been significantly expanded to include binding, TLS, and HTTP/3 QUIC transport tuning parameters. If your code instantiates ``NettyEndpointConfiguration`` directly (such as in custom endpoints or integration tests), you must update your constructor calls to include these new parameters: * ``bindAddress`` (String, nullable) * ``bindPort`` (int) * ``tlsCertificate`` (X509Certificate, nullable) * ``tlsPrivateKey`` (PrivateKey, nullable) * ``http3AltSvcMaxAgeSeconds`` (Uint32) * ``http3InitialMaxData`` (Uint64) * ``http3InitialMaxStreamDataBidirectionalRemote`` (Uint64) * ``http3InitialMaxStreamsBidirectional`` (Uint32) The example of the new approach follows: .. code-block:: java final var configuration = new NettyEndpointConfiguration( ERROR_TAG_MAPPING, PrettyPrintParam.FALSE, Uint16.ZERO, Uint32.valueOf(1000), "rests", MessageEncoding.JSON, serverStackGrouping, CHUNK_SIZE, FRAME_SIZE, ALT_SVC_HEADER, bindAddress, bindPort, tlsCertificate, tlsPrivateKey, Uint32.valueOf(3600), // http3AltSvcMaxAgeSeconds Uint64.valueOf(4L * 1024 * 1024), // http3InitialMaxData Uint64.valueOf(256L * 1024), // http3InitialMaxStreamDataBidirectionalRemote Uint32.valueOf(100)); // http3InitialMaxStreamsBidirectional Additionally, if you maintain custom Karaf features that package RESTCONF, you must add the new HTTP/3 dependencies to your ``feature.xml``: .. code-block:: xml odl-netty-http3 odl-netty-quic Remove ConfigUtils.serverTransport{Tcp,Tls} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Some previously-deprecated methods were removed. Their replacements live in ``HTTPServerOver{Tcp,Tls}``. .. code-block:: java final var serverTransport = HTTPServerOverTcp.of(localAddress, CONTROLLER_PORT); AAA Impacts ----------- Refactor initial domain creation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There is no longer a need to add a default domain into ``StoreBuilder``. For more info, follow: `AAA-295 `__. GNMI Impacts ------------ .. note:: The **gNMI (gRPC Network Management Interface)** project is now officially included as a Managed Project starting with the Chromium release. See the `gNMI GitHub repository `__ for more details. Rework GnmiSouthboundModule initialization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Due to changes made in the latest Chromium gNMI release, we will no longer be providing ``CrossSourceStatementReactor`` to ``GnmiSouthboundProvider`` as it is no longer used, and was replaced with ``YangParserFactory`` and ``YangTextToIRSourceTransformer``. New usage: .. code-block:: java final var gnmiProvider = new GnmiSouthboundProvider( domMountPointService, dataBroker, rpcProviderService, gnmiExecutor, prepareByPathLoaders(gnmiConfiguration), encryptionService, parserFactory, textToIrTransformer); gnmiProvider.init();