[CONTROLLER-1300] Allow user upgrade from Helium to Lithium with user config Created: 08/May/15  Updated: 19/Oct/17  Resolved: 24/Nov/15

Status: Resolved
Project: controller
Component/s: config
Affects Version/s: Post-Helium
Fix Version/s: None

Type: Bug
Reporter: Colin Dixon Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Issue Links:
Blocks
is blocked by CONTROLLER-1339 categorize YANG model changes from He... Resolved
External issue ID: 3160

 Description   

This is broader issue than just controller's config subsystem, but in general there is no documented upgrade procedure for a user to take a running Helium controller and upgrade it to a running Lithium controller (possibly shutting it down in the process).

Some discussion has happened on the mailing lists:
https://lists.opendaylight.org/pipermail/tsc/2015-May/003021.html

On the MD-SAL interest call:
https://meetings.opendaylight.org/opendaylight-meeting/2015/md_sal_interest_call/opendaylight-meeting-md_sal_interest_call.2015-05-05-16.02.html

And during the TSC meeting:
https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-05-07-17.01.html

The highest order bits to start discussion were:
There were differences of opinion in how exactly to handle it ranging from:

1.) It should be something automatic that happens in the actual ODL project
code so that you can just, shut down the controller, expand the new zip
file into the same place, run it again, and it will work and have all your
old config persisted.
2.) It should be done out-of-band with an upgrade script.
3.) We should just document the process people have to go through.
4.) We shouldn't do anything.

It was noted that a lot of this will have to be done on a per-project basis
since each project has different config and different data.

My personal take is that #3 is the bare minimum and we've asked for
information about that since the Hydrogen release notes [1] and I think at
least documenting what users should expect (and ideally providing them a
way to move without losing all of their configuration) is probably a really
good idea.

 Comments   
Comment by Colin Dixon [ 08/May/15 ]

As Tony pointed out during the TSC meeting, the first thing to do would be to see if we can just upgrade the container with no config persistence. That is, can we install Helium, boot it, do something, shut it down, install Lithium over it, delete config data, re-launch and see if it still works.

Comment by Tom Pantelis [ 11/May/15 ]

Another config file that needs to be upgraded is the configuration/initial/akka.conf for clustering. There shouldn't be anything that's incompatible but a couple knobs have been changed to improve things. Also a new message serializer has been added where a certain uncommon code path will bork w/o it.

The seed-nodes and role sections are what users would change so these would need to be reapplied on top of the new akka.conf, either manually or with a script.

In order to get the new akka.conf though, a user would have to move off the current one and start the controller to get the feature to lay down the new one.

Comment by Colin Dixon [ 26/May/15 ]

@Tony points out that if we just copy the zip over the existing installed distribution, we'll roughly double the size of the installation since we'll have two copies of most bundles. I will open a second bug to track that, but it should be low priority since we don't have an installation process anyway.

Comment by Colin Dixon [ 29/May/15 ]

The solution to BUG3377 should help in at least understanding what data models will/won't be compatible between Helium and Lithium.

Comment by Colin Dixon [ 18/Aug/15 ]

Tony also points out that renaming features may also cause issues.

Generated at Wed Feb 07 19:55:11 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.