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 email@example.com https://lists.opendaylight.org/mailman/listinfo/controller-dev