2021.09 Phosphorus Platform Upgrade
===================================
-This document describes the steps to help users upgrade from Aluminium
-to Silicon planned platform. Refer to `Managed Release Integrated (MRI)
+This document describes the steps to help users upgrade from Silicon
+to Phosphorus planned platform. Refer to `Managed Release Integrated (MRI)
project <https://git.opendaylight.org/gerrit/q/topic:phosphorus-mri>`_
upgrade patches for more information.
Before performing platform upgrade, do the following to bump the odlparent
versions (for example, `bump-odl-version <https://github.com/skitt/odl-tools/blob/master/bump-odl-version>`_):
-1. Update the odlparent version from 8.1.1 to 9.0.2. There should
+1. Update the odlparent version from 8.1.1 to 9.0.6. There should
not be any reference to **org.opendaylight.odlparent**, except
- for 9.0.2. This includes custom feature.xml templates
+ for 9.0.6. This includes custom feature.xml templates
(``src/main/feature/feature.xml``), the version range should
be "[9,10)" instead of "[8.1,9)", "[5.0.3,6)" or any other variation.
.. code-block:: shell
- bump-odl-version odlparent 8.1.1 9.0.2
+ bump-odl-version odlparent 8.1.1 9.0.6
-2. Update the direct yangtools version references from 6.0.5 to 7.0.3,
+2. Update the direct yangtools version references from 6.0.5 to 7.0.8,
There should not be any reference to **org.opendaylight.yangtools**,
- except for 7.0.3. This includes custom feature.xml templates
+ except for 7.0.8. This includes custom feature.xml templates
(``src/main/feature/feature.xml``), the version range should
be "[7,8)" instead of "[6,7)".
.. code-block:: shell
- bump-odl-version yangtools 8.1.1 7.0.3
+ bump-odl-version yangtools 6.0.5 7.0.8
-3. Update the MD-SAL version from 7.0.6 to 8.0.0. There should not be
- any reference to **org.opendaylight.mdsal**, except for 8.0.0.
+3. Update the MD-SAL version from 7.0.6 to 8.0.5. There should not be
+ any reference to **org.opendaylight.mdsal**, except for 8.0.5.
.. code-block:: shell
- bump-odl-version mdsal 7.0.6 8.0.0
+ bump-odl-version mdsal 7.0.6 8.0.5
-4. Update the Controller version from 3.0.7 to 4.0.0. There should not be
- any reference to **org.opendaylight.controller**, except for 4.0.0.
+4. Update the Controller version from 3.0.7 to 4.0.3. There should not be
+ any reference to **org.opendaylight.controller**, except for 4.0.3.
.. code-block:: shell
- bump-odl-version controller 3.0.7 4.0.0
+ bump-odl-version controller 3.0.7 4.0.3
-5. Update the InfraUtils version from 1.9.6 to 2.0.2. There should not be
- any reference to **org.opendaylight.infrautils**, except for 2.0.2.
+5. Update the InfraUtils version from 1.9.6 to 2.0.6. There should not be
+ any reference to **org.opendaylight.infrautils**, except for 2.0.6.
.. code-block:: shell
- bump-odl-version infrautils 1.9.6 2.0.2
+ bump-odl-version infrautils 1.9.6 2.0.6
-6. Update the AAA version from 1.13.0 to 0.14.0. There should not be
- any reference to **org.opendaylight.aaa**, except for 0.14.0.
+6. Update the AAA version from 1.13.0 to 0.14.3. There should not be
+ any reference to **org.opendaylight.aaa**, except for 0.14.3.
.. code-block:: shell
- bump-odl-version aaa 0.13.2 1.14.0
+ bump-odl-version aaa 0.13.2 0.14.3
-7. Update the NETCONF version from 1.13.1 to 2.0.1. There should not be
- any reference to **org.opendaylight.netconf**, except for 2.0.1.
+7. Update the NETCONF version from 1.13.1 to 2.0.5. There should not be
+ any reference to **org.opendaylight.netconf**, except for 2.0.5.
.. code-block:: shell
- bump-odl-version netconf 1.13.1 2.0.1
+ bump-odl-version netconf 1.13.1 2.0.5
Install Dependent Projects
^^^^^^^^^^^^^^^^^^^^^^^^^^
</dependency>
+Jackson minor version update
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The release stream for Jackson has been changed, we are now tracking the ``2.12.x`` release train. This means that
+references to the corresponding feature need to be updated to point to ``odl-jackson-2.12``.
+
+
YANG Tools Impacts
------------------
EffectiveStatementInference inference = SchemaInferenceStack.ofSchemaPath(context, node.getPath()).toInference();
+Strictly-compliant `leafref` path interpretation
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Previous versions of YANG Tools have had a number of ways how to resolve where a ``leafref``'s ``path`` statement is
+pointing to. Each of these operated on a different set of assumptions and had its share of caveats and outright bugs --
+most of them stemming from their attempt to operate on raw strings as declared in YANG files.
+
+All of these utilities have been removed in this release and superseded by a single implementation in aforementioned
+``SchemaInferenceStack``. This implementation maintains an
+`XPath Context <https://datatracker.ietf.org/doc/html/rfc7950#section-6.4.1>`__ and performs unqualified name resolution
+based upon its rules.
+
+Low-level API is ``SchemaInferenceStack.resolvePathExpression()``, which takes a ``PathExpression`` and interprets it
+in the context of its current state. On successful return the statement which the expression points will be return and
+the stack will be updated to be at that statement.
+
+High-level API is captured in ``LeafrefResolver`` API, allowing users to (recursively) resolve the actual type that a
+particular ``LeafrefTypeDefinition`` points to. SchemaInferenceStack is its canonical implementation.
+
+End-user visible behavior has changed in that incorrect leafref paths are now readily identified. This typically affects
+cross-module use of ``type leafref`` with absolute paths in either ``typedef`` or in ``grouping`` contexts. Typical source
+of trouble looks like this:
+
+ .. code-block:: yang
+
+ module foo {
+ prefix foo;
+
+ typedef foo-ref {
+ type leafref {
+ path /foo;
+ }
+ }
+
+ leaf foo {
+ type string;
+ }
+ }
+
+ module bar {
+ prefix bar;
+
+ import foo {
+ prefix foo;
+ }
+
+ leaf bar {
+ type foo:foo-ref;
+ }
+ }
+
+Note how ``foo-ref`` is using an absolute path with unqualified name. The intent seems to be to point at the ``foo:foo``
+leaf and in fact all uses within ``foo`` module operate as expected. In the context of ``bar`` module, though, things
+break down. When we are looking at ``bar:bar`` leaf, the path becomes ``/bar:foo`` -- and thus attempts to resolve it
+will fail. Correct fix in this situation is to correct the definition of the path to use qualified names:
+
+ .. code-block:: yang
+
+ typedef foo-ref {
+ type leafref {
+ path /foo:foo;
+ }
+ }
+
+
Unrecognized YANG statement handling
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
YANG parser does not reflect unrecognized YANG language extensions, defined by
Code Review / docs.git / blobdiff