Create update.sh

[whopperg]

This is my first take for a update solution for manual installations. Hopefully this is the correct path. If not, please point me to the right direction.

[ThomDietrich]

Related to #299

[ThomDietrich]

Hey, let's discuss extensions. Out of my head:

• Decouple Backup, Restore and Upgrade
• Use upgrade-operations.csv file (example file name)

@kaikreuzer I do not know of any wide-spread format nor did I find one on the internet. I can't think of any higher complexity (delete file x only if file y diesn't exist and z was created on christmas eve) demanding a more sophisticated format. Here are all examples I can think of:

• DELETE;relative/path/to/file
• DELETE;$OPENHAB_CONF/pseudo-relative/path/to/file
• MOVE;filepath_old;filepath_new
• MOVE;filepath_old;filepath_new
• TOUCH;some_file_or_folder (probably not needed, will create folders which might be of interest)

General remarks:

• All commands should be executed in the order they are given in the file
• paths are relative and can start with one of the defined $OPENHAB variables
• path delimiter is the forward slash
• paths can contain wildcards * and ?
• spaces and tabs are to be ignored

One additional idea: A second parameter could contain either of ERROR/WARN/INFO/NONE telling the upgrade script how to react on a problem, e.g. file to move doesn't exist, ...

What do you think?

[kaikreuzer]

Sounds fine to me. Maybe we could also introduce an APPEND besides DELETE/MOVE/TOUCH.
Logging level infos might be a good idea, yes.

Do we also support wildcards in filenames?

[BClark09]

batch and sh should be able to support * and ? wildcards in filenames.

[ThomDietrich]

APPEND content to file, e.g. add new option to a config file without changing existing settings? Sounds handy but might be too much for the csv file. There are too many edge cases... Maybe we should look into diff / a diff variant is the better approach then!?

Wildcards are okay with me. (adding above)

[whopperg]

I like the idea of diff very much. I'll guess this cloud be easily implemented using rsync...

[kaikreuzer]

Maybe we should look into diff / a diff variant is the better approach then!?

That's what I wanted to avoid.

I'll guess this cloud be easily implemented using rsync...

On Windows???

With APPEND I thought that a new version could simply add a new setting to the end of an existing file by just delivering the diff. But you might be right that that as well can become complex easily, especially as soon as people skip some release inbetween. Btw, do we have any good strategy to handle that case?

[ThomDietrich]

Okay, let's not get ahead of ourselves and try to get a first version ready.

My understanding of this PR is an upgrade script. Should this be its only purpose or do we want to break it down to four parts: backup, restore, migrate, upgrade? Upgrade executes 1-3 (plus the actual upgrade) and Migrate would be what we discussed above.

Would you agree it would be better to first get Backup, Restore and Upgrade finished and merged before we look into migration?

[whopperg]

Just to be clear: this script is at first, anyways, for upgrade a manual installation only. So there is anything in there (backup, upgrade, restore). We just need to define which files are need to be copied back to the upgraded installation so that we got as little manual reconfiguring as possible (at least this was my intention:-))

On the other hand, a upgrade procedure for all possible scenarios (like different Linux distros, Windows and so on) would be nice, but I guess not possible at all. So we should think about that we might have seperated routines per Linux/Windows.

[kaikreuzer]

a upgrade procedure for all possible scenarios (like different Linux distros, Windows and so on) would be nice, but I guess not possible at all.

Why? This is exactly what we wanted to achieve with the csv - to have a platform independent file, which the platform dependent scripts will use (the scripts only have to be created once, while the csv will be modified over time).

[whopperg]

Ah ok, i've misunderstood that part with the platform dependent scripts.

[whopperg]

So lets recap:
we need a csv with ACTION;SOURCE_PATH/FILE;DESTINATION_PATH/FILE.
Action could be: DELETE, MOVE, COPY, TOUCH

Some Examples:
DELETE;/opt/openhab2/tmp/some.log
DELETE;/opt/openhab2/tmp/somepath
MOVE;/opt/openhab2/userdata;/opt/backup/openhab2-timestamp/userdata
MOVE;/tmp/extract/openhab2/runtime;/opt/openhab2/runtime
COPY;opt/backup/openhab2-timestamp/userdata;/opt/openhab2/userdata
TOUCH;opt/openhab2/userdata/somefolder

What we try to accomplish is the following:

1. Make a Backup of current setup to user? specific path.
2. Download the current SNAPSHOT archive and extract it to user? specific path.
3. Copy/Move files from extracted archive to DESTINATION path.
4. Copy specific files from backup to DESTINATION path as needed.
5. TOUCH specific files/folders in DESTINATION path as needed.

I'll say that the whole process should generate a logfile where everything is logged to.

[kaikreuzer]

This is now superseded by #471, but we should soon continue on the discussion of the CSV processing and additional backup/restore scripts as well. Shall we do this on this PR or open dedicated issues instead for the discussions?