[updater] A component for self-updating openHAB via the UI

[andrewfg]

This is a first attempt at creating a core module which supports self- updating of OpenHAB via the UI.

This PR is made available to allow OpenHAB maintainers to review the code and give feedback.

It is only a proof of concept (or not). It is not yet intended to be merged at this time.

Instructions: build the jar, drop it in /addons, and then go to Developer Tools | Api Explorer | Update

Signed-off-by: Andrew Fiddian-Green software@whitebear.ch

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/addon-to-update-oh-thoughts-anyone/121576/11

[andrewfg]

Dear All,
The first reviewers focussed on the UI of this module. There is nothing wrong with that, but IMHO the real focus should be on the functionality rather than the UI. In particular I would suggest (indeed request) some feedback on the following items..

• The BaseUpdater class, in particular the way it builds the update scripts and injects them into the operating system shell.
• The classes that extend from BaseUpdater for specific OS; the WindowsUpdater and DebianUpdater are tested, but the others (Mac, Yum, PacMan, Portage, etc.) need someone who uses those systems.
• The update script templates associated with the respective OS updaters DebianUpdater.txt, WindowsXX.txt etc. etc.

[andrewfg]

@kaikreuzer I have made some changes based on your recent feedback. However unfortunately by changing the version from 3.1.0-SNAPSHOT to 3.2.0-SNAPSHOT this PR seems to have "acquired" the 370 or so files that changed when 3.1.0 was released. It is now a mess, and I don't know how to fix that.

[andrewfg]

unfortunately by changing the version from 3.1.0-SNAPSHOT to 3.2.0-SNAPSHOT this PR seems to have "acquired" the 370 or so files that changed when 3.1.0 was released

@kaikreuzer the above-mentioned issue has now been resolved :)

[andrewfg]

#2372 (comment)

@kaikreuzer resolved

[andrewfg]

@kaikreuzer => ping!

[andrewfg]

Just to report that this did successfully install 3.2.M2 today (see screenshot below)..

[kaikreuzer]

Cool! Will look at it soon®, promised, @andrewfg!

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/validation-api-usage/126439/1

[kaikreuzer]

Hey @andrewfg! Very sorry that it took so long, but finally I now had a closer look at it and also tested it on macOS.
The code of the PR looks pretty clean, thanks for the good job on it!

Unfortunately, I didn't manage to get it working on macOS. I made a couple of fixes (like also setting the executable flag on the script, calling it as the provided user and not as root, etc.), but the execution of the single steps always fails as the commands expect to be run in some other folder. Manually calling it during my tests it behaved differently than when being called from the JVM and I couldn't really figure out how to fix it.

Thinking about it, I also wasn't sure how the script should actually know, how to correctly start the instance. Some people run it through "bin/karaf start", others might use "bin/start", I am running it within screen, others might do nohup or special service wrappers. I somehow doubt that there's a solution that will just work and not be very fragile.
I have the same concerns for Windows users - the current script simply starts the instance, but what if people run it as a Windows service as described here?
On Linux, the code assumes that openHAB is installed through the package manager of the distro. But what if it is manually installed or used as a snap in a docker container?

The more I think about it, the less convinced I am that we can get this a stable feature.
Happy to discuss how to proceed - also inviting the other @openhab/core-maintainers.

[wborn]

The more I think about it, the less convinced I am that we can get this a stable feature.

We might just only want to provide APIs here in core, so the UI knows if an update mechanism is available, and what parameters are used (password, available versions). Then the actual update script(s) and files that supply the parameters can move to distro projects. It would also allow users to have a way to plug-in their own update mechanism if they use something of their own. The available versions also depends on what installation method is used. E.g. versions aren't always immediately available for all platforms/installation methods (Synology, snap, etc).

[andrewfg]

might just only want to provide APIs here in core, so the UI knows if an update mechanism is available, and what parameters are used (password, available versions). Then the actual update script(s) and files that supply the parameters can move to distro projects.

This is essentially what I did already. There is a main API with a REST GET to read the current update state, and a POST to start the update process. And then for each type of installation / distro there are just two distro specific elements — namely i) a small Java class that extends/ overrides some methods in the main updater class, and ii) a text file that contains the update command script.

I have only written these two elements for OpenHabian an Windows so far..

[wborn]

IMHO the core should not know anything about package specific upgrade commands. It should only know that there is a script (or class) that can do this and what kind of parameters it expects that can then be provided using the UI. I.e. it uses some abstraction where the package adds a file or property to indicate it can do the update using what parameters. Then the actual upgrade scripts move to either openhab-distro, openhab-linuxpkg, openhab-syno-spk, openhab-snap etc where they can be maintained and which already have all the package specific implementation details.

[andrewfg]

the core should not know anything about package specific upgrade commands. It should only know that there is a script (or class) that can do this and what kind of parameters it expects that can then be provided using the UI

Indeed. (That is what I am doing). The scripts contain placeholders for parameters like target version, target version type, password etc. and the core replaces the placeholders in the scripts.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/upgrading-system-via-gui/138453/13

[J-N-K]

@andrewfg What is the state here?

[andrewfg]

What is the state here?

I think it is 'sleeping' .. @kaikreuzer / @wborn WDYT? .. if you agree we can close it, or make it WIP ..

[kaikreuzer]

I think the latest state of discussion was @wborn's suggestion above and I agree with this.
In consequence, any specific updater code should be removed from this PR and be moved to other repos instead.
I am just not sure yet, whether there is a reliable mechanism in place already, which can determine, what installation type has been used and hence, which script (if available) should be used for it.

[Skinah]

Would love to see this merged one day.