Here is the link to the known issues exist in this release:
-`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+serviceutils+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
\ No newline at end of file
+`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+serviceutils+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
.. note::
this could be a karaf feature or new functionality made available
- as a new implementation of an already exisiting karaf feature.
+ as a new implementation of an already existing karaf feature.
Deprecated Features
===================
JDK 11 Version
^^^^^^^^^^^^^^
Silicon requires Java 11, both during compile-time and run-time.
-Make sure to install JDK 11 corresponding to at least openjdk-11.0.8,
+Make sure to install JDK 11 corresponding to at least ``openjdk-11.0.8``,
and that the JAVA_HOME environment variable points to the JDK directory.
InfraUtils is a MRI project
1. Update the odlparent version from 7.0.5 to 8.1.1. There should
not be any reference to **org.opendaylight.odlparent**, except
for 8.1.1. This includes custom feature.xml templates
- (src/main/feature/feature.xml), the version range there should
+ (``src/main/feature/feature.xml``), the version range should
be "[8.1,9)" instead of "[8,9)", "[5.0.3,6)" or any other variation.
.. code-block:: shell
2. Update the direct yangtools version references from 5.0.5 to 6.0.5,
There should not be any reference to **org.opendaylight.yangtools**,
except for 6.0.5. This includes custom feature.xml templates
- (src/main/feature/feature.xml), the version range there should
+ (``src/main/feature/feature.xml``), the version range should
be "[6,7)" instead of "[5,6)".
.. code-block:: shell
Augmentation tracking has been reworked
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-As part of larger lifecycle activities, a number of implementation details
+As part of larger life-cycle activities, a number of implementation details
have changed to the point as to render the distinction between Augmentable
and AugmentationHolder interfaces superfluous. AugmentationHolder has therefore
been completely integrated into Augmentable allowing efficient implementation
Interfaces for invocation of ``RPCs`` and ``actions``, as well as
publishing ``notifications`` have switched from using ``SchemaPath`` to
using either ``QName`` or ``SchemaNodeIdentifier.Absolute``. This allows
-more efficient invocation and removes ambguity around relative SchemaPath
+more efficient invocation and removes ambiguity around relative SchemaPath
being or not being allowed.
Removed packaging of draft ietf-topology extensions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-As part of furtherm cleanup, standardization and stabilization of MD-SAL
+As part of further cleanup, standardization and stabilization of MD-SAL
interfaces, four models from ``draft-clemm-netmod-yang-network-topo-01``
have been removed: ``ietf-topology-isis``, ``ietf-topology-ospf``, ``ietf-ted``
and ``ietf-topology-l3-unicast-igp``. For further details see this
Final release to include widened Integer/Long/BigInteger compatibility
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Magnesium introduced a change in how uint8, uint16, uint32 and uint64 types
-are mapped to Java. Previously this would be mapped to Short, Integer, Long
-and BigInteger respectively. With Magnesium these are mapped to dedicated
-yang.common.Uint{8,16,32,64}, whose design matches general design of
-java.lang.Integer.
+Magnesium introduced a change in how ``uint8``, ``uint16``, ``uint32`` and
+``uint64`` types are mapped to Java.
+Previously this would be mapped to Short, Integer, Long and BigInteger
+respectively.
+With Magnesium these are mapped to dedicated ``yang.common.Uint{8,16,32,64}``,
+whose design matches general design of ``java.lang.Integer``.
This change obviously requires some amount adaptation, which is why
-compatibility setter methods and contructors are generated, each of which
+compatibility setter methods and constructors are generated, each of which
converts the wide type to its native mapping, undoing the widening.
Such conversions are costly in terms of both CPU usage, but also cost
Akka remote configuration
^^^^^^^^^^^^^^^^^^^^^^^^^
-Because of the akka upgrade to 2.6.x in Silicon, remote tcp configuration changed
+Because of the akka upgrade to 2.6.x in Silicon, remote TCP configuration changed
from ``netty.tcp`` to ``classic.netty.tcp``:
.. code-block:: none
port = 2550
}
-Use of odl:type in Blueprint is discouraged
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Use of ``odl:type`` in Blueprint is discouraged
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This property has been used for discerning between various implementations
of MD-SAL services present in the OSGi service registry. As these services have
been consolidated in the past couple of releases, the use of this qualifier
-is discouraged. While some services are advertized with this property set, it
+is discouraged. While some services are advertised with this property set, it
is no longer considered a binding contract and future releases, even minor,
will most likely stop adding this property.
Cloning Autorelease
===================
-To clone all the autorelease repo including it's submodules simply run the
-clone command with the '''--recursive''' parameter.
+To clone all the autorelease repository including it's ``submodules`` simply
+run the clone command with the '''--recursive''' parameter.
.. code-block:: bash
git clone --recursive https://git.opendaylight.org/gerrit/releng/autorelease
If you forgot to add the --recursive parameter to your git clone you can pull
-the submodules after with the following commands.
+the ``submodules`` after with the following commands.
.. code-block:: bash
other fields to their default setting. Set this to Boron, Boron-RC0,
Boron-RC1, etc... depending on the build you'd like to create.
-Adding Autorelease staging repo to settings.xml
-===============================================
+Adding Autorelease staging repository to settings.xml
+=====================================================
If you are building or testing this release in such a way that requires pulling
-some of the artifacts from the Nexus repo you may need to modify your
-settings.xml to include the staging repo URL as this URL is not part of ODL
-Nexus' public or snapshot groups. If you've already cloned the recommended
-settings.xml for building ODL you will need to add an additional profile and
-activate it by adding these sections to the "\<profiles\>" and
-"\<activeProfiles\>" sections (please adjust accordingly).
+some of the artifacts from the Nexus repository you may need to modify your
+``settings.xml`` to include the staging repository URL as this URL is not part
+of OpenDaylight Nexus' public or snapshot groups.
+If you've already cloned the recommended settings.xml for building ODL you will
+need to add an additional profile and activate it by adding these sections to
+the ``\<profiles\>`` and ``\<activeProfiles\>`` sections
+(please adjust accordingly).
.. note::
* This is an example and you need to "Add" these example sections to your
- settings.xml do not delete your existing sections.
- * The URLs in the \<repository\> and \<pluginRepository\> sections will also
- need to be updated with the staging repo you want to test.
+ ``settings.xml`` do not delete your existing sections.
+ * The URLs in the ``\<repository\>`` and ``\<pluginRepository\>`` sections
+ will also need to be updated with the staging repository you want to test.
.. code-block:: xml
stream: silicon
branch: stable/silicon
-#. Review and submit the changes to releng/builder project. **(releng/builder committers)**
+#. Review and submit the changes to releng/builder project.
+ **(releng/builder committers)**
Autorelease
-----------
-#. Block submit permissions for registered users and elevate RE's committer rights on gerrit.
+#. Block submit permissions for registered users and elevate RE's committer
+ rights on Gerrit.
**(Helpdesk)**
.. figure:: images/gerrit-update-committer-rights.png
Enable **Exclusive** checkbox for the submit button to override any existing permissions.
-#. Enable create reference permissions on gerrit for RE's to submit .gitreview patches.
+#. Enable create reference permissions on Gerrit for RE's to submit
+ ``.gitreview`` patches.
**(Helpdesk)**
.. figure:: images/gerrit-update-create-reference.png
#. Start the branch cut job or use the manual steps below for branch cutting autorelease. **(Release Engineering Team)**
#. Start the version bump job or use the manual steps below for version bump autorelease. **(Release Engineering Team)**
-#. Merge all .gitreview patches submitted though the job or manually. **(Release Engineering Team)**
-#. Remove create reference permissions set on gerrit for RE's. **(Helpdesk)**
+#. Merge all ``.gitreview`` patches submitted though the job or manually. **(Release Engineering Team)**
+#. Remove create reference permissions set on Gerrit for RE's. **(Helpdesk)**
#. Merge all version bump patches in the order of dependencies. **(Release Engineering Team)**
-#. Re-enable submit permissions for registered users and disable elevated RE committer rights on gerrit. **(Helpdesk)**
+#. Re-enable submit permissions for registered users and disable elevated RE committer rights on Gerrit. **(Helpdesk)**
#. Notify release list on branch cutting work completion. **(Release Engineering Team)**
Manual steps to branch cut (Autorelease)
----------------------------------------
-#. Setup releng/autorelease repository.
+#. Setup ``releng/autorelease`` repository.
**(Release Engineering Team)**
.. code-block:: bash
git pull --rebase
git submodule foreach 'git pull --rebase'
-#. Enable create reference permissions on gerrit for RE's to submit .gitreview patches.
+#. Enable create reference permissions on Gerrit for RE's to submit
+ ``.gitreview`` patches.
**(Helpdesk)**
.. figure:: images/gerrit-update-create-reference.png
Enable Exclusive check-box override any existing permissions.
-#. Create stable/${CURR_RELEASE} branches based on HEAD master.
+#. Create ``stable/${CURR_RELEASE}`` branches based on HEAD master.
**(Release Engineering Team)**
.. code-block:: bash
git push gerrit stable/${CURR_RELEASE,,}
git submodule foreach 'git push gerrit stable/${CURR_RELEASE,,}'
-#. Contribute .gitreview updates to stable/${CURR_RELEASE,,}.
+#. Contribute ``.gitreview`` updates to ``stable/${CURR_RELEASE,,}``.
**(Release Engineering Team)**
.. code-block:: bash
git checkout pom.xml scripts/
-#. Push version bump master changes to gerrit. **(Release Engineering Team)**
+#. Push version bump master changes to Gerrit. **(Release Engineering Team)**
.. code-block:: bash
Finding the Managed Projects given a Managed Distribution
=========================================================
-Given a Managed Distribution (tar.gz, .zip, RPM, Deb), the Managed Projects
-that constitute it can be found in the `taglist.log` file in the root of the
-archive.
+Given a Managed Distribution (``.tar.gz``, ``.zip``, RPM, Deb), the Managed
+Projects that constitute it can be found in the `taglist.log` file in the root
+of the archive.
`taglist.log` files are of the format:
CLM
+++
-Managed Projects are required to handle CLM (Component Lifecycle Management)
+Managed Projects are required to handle CLM (Component Life-cycle Management)
violations in a timely manner.
Managed Release Process
Midway Checkpoint
#################
-One month before code freeze, a midway checkpoint will be collected. The release team
-will review the information collected and report it to the TSC at the next TSC
-meeting. All information for midway checkpoint will be automatically collected.
+One month before code freeze, a midway checkpoint will be collected.
+The release team will review the information collected and report it to the TSC
+at the next TSC meeting.
+All information for midway checkpoint will be automatically collected.
* Open Jira bugs marked as blockers.
* Open Jira issues tracking weather items.
Final Checkpoint
################
-At 2 weeks after code freeze a final checkpoint will be collected by the release team
-and presented to the TSC at the next TSC meeting.
+At 2 weeks after code freeze a final checkpoint will be collected by the release
+team and presented to the TSC at the next TSC meeting.
Projects will need to create the following artifacts:
The TSC vote at any time to back out of a version bump if the new releases are
found to be unsuitable.
-MRI Projects are expected to provide bugfixes via minor or patch version
+MRI Projects are expected to provide bug fixes via minor or patch version
updates during the release, but should strive to not expect MSI Projects to
consume another major version update during the release.
In order to be included in the formal (major or service) release distribution,
Self-Managed Projects must be in the common distribution pom.xml file and the
-distribution sanity test (see :ref:`add-proj-dist`) no later than one week before
-the first Managed release candidate (RC) is created. Projects should only be added
-to the final distribution pom.xml after they have succesfully published artifacts
-using upstream SNAPSHOTs. See `Use of SNAPSHOT versions`_.
+distribution sanity test (see :ref:`add-proj-dist`) no later than one week
+before the first Managed release candidate (RC) is created.
+Projects should only be added to the final distribution pom.xml after they have
+successfully published artifacts using upstream SNAPSHOTs.
+See `Use of SNAPSHOT versions`_.
.. note:: It is very important Self-Managed projects do not miss the deadlines for
upstream integration and final distribution check, otherwise there are
Self-Managed projects wanting to use the existing release job to release their
artifacts (see `Release the project artifacts`_) must have an stable branch in
-the major release (fluorine, neon, etc) they are targeting. It is highly recommended
-to cut the stable branch before the first Managed release candidate (RC) is created.
+the major release (fluorine, neon, etc) they are targeting.
+It is highly recommended to cut the stable branch before the first Managed
+release candidate (RC) is created.
After creating the stable branch Self-Managed projects should:
-* Bump master branch version to X.Y+1.0-SNAPSHOT, this way any new merge in master
- will not interfere with the new created stable branch artifacts.
+* Bump master branch version to X.Y+1.0-SNAPSHOT, this way any new merge in
+ master will not interfere with the new created stable branch artifacts.
-* Update .gitreview for stable branch: change defaultbranch=master to stable branch.
- This way folks running "git review" will get the right branch.
+* Update ``.gitreview`` for stable branch: change ``defaultbranch=master`` to
+ stable branch. This way folks running "git review" will get the right branch.
-* Update their jenkins jobs: current release should point to the new created stable
- branch and next release should point to master branch. If you do not know how to
- do this please open a ticket to opendaylight helpdesk.
+* Update their jenkins jobs: current release should point to the new created
+ stable branch and next release should point to master branch.
+ If you do not know how to do this please open a ticket to OpenDaylight
+ helpdesk.
Release the project artifacts
+++++++++++++++++++++++++++++
---------------------------------------------
Managed Projects that are not required for dependency reasons can submit a
-**Project_Plan** issue to be Self-Managed to the TSC project in Jira. See details
-in the `Initial Checkpoint`_ section above. Requests should be submitted before
-the start of a release. Requests will be evaluated by the TSC.
+**Project_Plan** issue to be Self-Managed to the TSC project in Jira.
+See details in the `Initial Checkpoint`_ section above.
+Requests should be submitted before the start of a release.
+Requests will be evaluated by the TSC.
The TSC may withdraw a project from the Managed Release at any time.
Self-Managed Projects will have their artifacts included in the final release
if they are available on-time, but they will not be available to be installed
-until the user does a repo:add.
+until the user does a `̀ repo:add``.
To install an Self-Managed Project feature, find the feature description in the
system directory. For example, NetVirt's main feature:
-system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/
+.. code-block:: none
-Then use the Karaf shell to repo:add the feature:
+ system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/
-feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0
--SNAPSHOT/xml/features
+Then use the Karaf shell to ``repo:add`` the feature:
+
+.. code-block:: none
+
+ feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/xml/features
Grievances
==========
* Self-Managed Project: A project not taking part in the Managed Release
Process.
* Simultaneous Release: Event wherein all Snapshot Integrated Project versions
- are rewriten to release versions and release artifacts are produced.
+ are rewritten to release versions and release artifacts are produced.
* Snapshot Integrated Project: Project that integrates with OpenDaylight
projects using snapshot version numbers. These projects release together in
the Simultaneous Release.
-*****************
-Project lifecycle
-*****************
+******************
+Project life-cycle
+******************
This page documents the current rules to follow when adding and removing
a particular project to Simultaneous Release (SR).
The project is not recognized by Technical Steering Committee (TSC) to be
part of OpenDaylight (ODL).
- **non-participating**
- The project is recognized byt TSC to be an ODL project, but the project has
- not confirmed participation in SR for given release cycle.
+ The project is recognized by the TSC to be an ODL project, but the
+ project has not confirmed participation in SR for given release cycle.
- **non-building**
The recognized project is willing to participate, but its current codebase is
not passing its own merge job, or the project artifacts are otherwise
but autorelease build fails when building project's artifact.
Temporary state, timing out into not-in-autorelease.
- **repo-not-in-integration**
- Project is succesfully built within autorelease, but integration/distribution:features-index
+ Project is successfully built within autorelease, but integration/distribution:features-index
is not listing all its public feature repositories.
- **feature-not-in-integration**
Feature repositories are referenced, distribution-check job is passing,
.. todo::
- - Add links to documents concerning project lifecycle from TSC point of view.
+ - Add links to documents concerning project life-cycle from TSC point of view.
- Add links to M# templates, test requirements and other relevant info.
- Mention other jobs involved in verification (verify, validate-autorelease, ... releng-check-poms).
- Add back-references to this document (from integration/distribution, job definition templates, ...).
ACL
+Akka
+Aluminium
Autorelease
+augmentable
autorelease
+aaa
abelur
+akka
analytics
+BigInteger
+codebase
config
+Disruptor
+datastores
deliverables
dev
eg
Gerrit
Git
GPG
+hardcoded
helpdesk
+ietf
+infrautils
Jenkins
Jira
jamoluhrsen
Karaf
karaf
lftools
+Magnesium
+mdsal
+muxponders
netvirt
+netconf
OpenDaylight
OpenFlow
-odl
+OpenStack
+odlparent
ovs
ovsdb
pre
reachability
+reconfigurable
+reimplemented
releng
+renderer
rovarga
+submodule
+switchponders
+TCP
TSC
+todo
tsc
uncheck
+vTEP
virtualenv
+yangtools
xml
of at least one OpenDaylight component.
There are indirect ways to deduce such version, but the direct way is enabled
-by odl-distribution-version feature. Administrator can specify version strings,
+by ``odl-distribution-version`` feature. Administrator can specify version strings,
which would be available to users via NETCONF, or via RESTCONF
if OpenDaylight is configured to initiate NETCONF connection
to its config subsystem northbound interface.
Code Review / docs.git / commitdiff