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

Reply via email to