Hi everyone,
Going through the various releases of ODL, it
appears that currently, there is no implied backward compatibility between
releases. Consequently, in a production environment, it would require a
complete reinstallation of ODL whenever we need to move to a new version of ODL.
We would like to contribute towards a project that focuses on
the Upgradability of ODL. We have done some initial analysis and identified a
number of requirements on ODL that need to be met for upgrades to be
successful. They are reproduced below:
Use Case
ATM-Title
Sub use case Title
Use case description
1
Configuration Preservation
Data model translation
It must be possible for the ODL to read and translate an earlier version CDS to
a newer version of CDS. The CDS can change due to changes in the data-model and
changes in the interface definitions.
Rollback Configuration Translation
When a upgrade procedure is initiated, the configuration state of the system
must be persisted in both the current version and the earlier version. This is
because, in some middlewares, the same procedure can be initiated to do
rollbacks and the controller may not have mechanisms to know whether it is an
upgrade scenario or a rollback scenario.
Upgrade component Configuration Translation
As a part of deployment, the operator may override ODL the default values in
the configuration files such as karaf.cfg, system.properties, etc. During
upgrades, these changes must not be lost (unless the support for a specific
configuration is deprecated). It must be migrated to the next version.
2
Multi API support
OVS API support
Whenever a new ODL release does requires a new version of OVS to support newer
features, both ODL and OVS will be jointly upgraded. ODL must be upgraded first
(so that in case of a rollback, a rollback of all the OVS installations would
not be required).
OVS installations must be upgraded one at a time to avoid significant impact to
the data-plane. This implies that during OVS upgrade, the ODL must seamlessly
interact with both versions of OVS. During upgrade, ODL must not send OF/OVSDB
messages that are unsupported by the earlier version of OVS.
Open Stack Multi API support
To support seamless interaction with Openstack, it must be possible for ODL to
support multiple versions of Neutron APIs (if they change across releases).
Rollback
It must be possible to rollback multiple components (Openstack, ODL, OVS) in a
seamless fashion without affecting data traffic and retaining configuration
3
Single Step Upgrade
Single Step Upgrade
It must be possible to upgrade all instances of a ODL cluster in one step. This
mechanism must be invoked whenever ODL data-model/interfaces change across
releases and the earlier versions of ODL cannot work seamlessly with a newer
version of ODL.
4
Rolling Upgrade
Rolling Upgrade
It must be possible to upgrade ODL instances one node at a time, to avoid
controller down time. It must be possible to invoke this mechanism, whenever
release upgrades have backward compatible data models and interfaces. In a
rolling upgrade, the controller cluster must continue to provide service to
both North Bound and South Bound applications during the course of the upgrade.
Our agenda for this email is part
1. We seek comments from the community on the idea.
2. We would like to some if there are like minded folks who are
interested in joining us in this regard.
3. We would like to know if there are any projects that are already that
are ongoing in this area and if yes, some links to the documents. If there is
no project in this area, should we create a new project.
4. We would like to inform that we are keen to contribute to this project.
Thanks,
Ashvin
_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
