This is a great idea Ashvin. Do you think a cross project activity (probably seeded in ODL infra utils project) would work or do you think it would be better to have a separate project? The advantage of having a separate project at first merged into an existing project later is that: development could be kick started faster. Reason: a new project means the activity has committers from within this new activity and no dependency on some other committers who may not have the time/commitment to review the code for this activity.
On Thu, Dec 1, 2016 at 11:20 PM, Ashvin Lakshmikantha < ashvin.lakshmikan...@ericsson.com> wrote: > 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 > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
