4.2: bundles automatically restored to their original version #3983
Comments
|
I also just noticed this. So it may be triggered by the addon suggestion functionality that (un)installs features. |
|
Yes. Whenever a feature is installed/uninstalled we refresh the other features, which results in a reset of the bundles to their original version. This also happens when you install/uninstall add-ons. |
|
Do we have behind the scene a new feature that is installed or uninstalled ? |
|
A custom Basic UI bundle does not survive after the restart of OH (4.2 snapshot 3808) ! I even do not understand why "Stopped Basic UI" is logged twice. But at least this log appears because Basic UI is uninstalled before being installed again with an old version, I guess the version downloaded from the WEB. It is a critical bug IMHO. Let's try now with 4.1 release... |
|
One good news is that I can't reproduce this scenario with 4.1 release: |
|
IIRC (we had a similar issue in the past) it only occurs between snapshots, not releases and snapshots. |
|
Here are logs with DEBUG logs from karaf. The added features at boot are openhab-core-config-discovery-addon-ip and openhab-core-config-discovery-addon-upnp. If I filter only most important lines: What is strange is:
|
|
If I do not update my bundle (Basic UI), the restart is clean. Maybe my problem is that the first time I restarted the server while not all the bundles were still installed ? |
|
I tried again from scratch, waiting enough beofre restarting the server. For an enigmatic reason, now you need to start the server three times before "being safe". |
|
My guess would be that if you restart over and over again, you'll lose the bundle. It's not fully deterministic. |
It seems it is working well at the third start and next ones, even if I update again my bundle. |
|
Regarding org.eclipse.jetty.http2/http2-hpack, any idea why it needs to be reinstalled each time you install a new add-on ? |
@lolodomo yes I made it un-installable in the same way that the mDNS, UPnP and IP finders are. But as I am no expert on feature installation, I just copied the other's code, so maybe I did something wrong, or overlooked something? |
I think the Jetty version was bumped. ?? So perhaps a binding is asking for a version different than the core had installed? Or something like that. PS have a look at the Hue binding, which was the first (maybe still only) one to introduce this dependency? |
Probably not. |
Looks like the proper version is installed and started. I assume thge important line is: |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/openhab-4-2-milestone-discussion/154316/103 |
|
@lolodomo If I understand this well, this issue is not specific to the suggestion finders, but it is aggrevated by it. It also pops up if you install a distribution add-on after you have installed a custom bundle. That will also make your custom bundle revert to the default. |
|
The issue with reverting bundles is the following code in On refresh the original version is installed from cache. I don't think there is a way to prevent that. IIRC simply removing it is not possible, some add-ons had resolving probems if we don't refresh. Regarding the 3rd party add-ons: The issue might be that installation if the features and refreshing of an older install results in a failing installation. Failed add-ons are removed from the list to prvent continous re-installation attempts. |
|
@J-N-K Comparing the feature installation for the suggestion finders and and in FeatureInstaller, I notice there are extra options used in FeatureInstaller: vs I couldn't find clear documentation on these extra options. Would adding these to the suggestion finder installer improve the situation? |
|
The options just suppress the error in case of a failed installation and the refreshing of the bundles after each installation (instead the code I posted above refreshes the bundles after everything is installed. I think it would probably be better if you used the |
These options have impact on behavior of entire system. Because openhab addon features are constructed in specific way (they usually depend on |
|
I have an issue that is likely related (or the same!). I've got a stock openhabian install running on a Pi, and if I install a custom zigbee binding (which is a fat kar) it doesn't survive a reboot. I've not installed the zigbee binding from the UI, although it does show it as being installed. Other custom JARs are fine in the addons folder are fine - they come back up when the system starts, but the zigbee binding always need to be removed from Is there any workaround to this? |
|
In my use case, I was not using custom jar/kar files but bundle:update command to update the existing bundles. |
|
The problem also occurs when a new addon is installed from the marketplace - ie if I install a new addon from the UI marketplace, then the custom zigbee binding gets uninstalled. This does make development of official bindings somewhat more difficult - @J-N-K do you have any thoughts as to why custom bundles are getting uninstalled? If this is considered to be a different issue, I'm happy to open a new issue. |
|
As soon as something is installed, all custom bundles are reverted. That is the known issue. |
|
Sure - but in my case, it's not exactly reverted - it's removed. I guess you can say this is reverted, since the zigbee binding was never installed, so I guess the fact that the system is removing it is in some view reverted. Either way, it makes it very annoying/difficult to develop with this issue. |
|
Removed in your use case, reverted in mine. |
|
Sure - understood - and both are not good ;) |
|
#3983 (comment) This explains what happens and why. We would need to change the way features are declared and probably add correct import statements in the manifest. |
|
Thanks. I guess the question is if anyone plans to look at this or if we have to live with it? If it's not going to be fixed, and there's no easy workaround, then it's a bit of a killer... |
|
Does it improve if you add to the BND instructions (in openhab-addons that would be around https://github.com/openhab/openhab-addons/blob/280f5c5beb53e95744122085bc45c3774c4ce1aa/pom.xml#L111 |
|
No - that doesn't seem to make any difference. |
|
So... The problem is even worse... When I drop in a new KAR, it is actually not used for the most part. I'd not noticed before, but the bundles that are loaded are from the addons snapshot, and not from the KAR. This KAR has one extra bundle for a new coordinator we've been testing, and this bundle does get loaded, so clearly the new KAR is recognised, but all other bundles are taken from the distribution rather than the KAR I've dropped in addons. Now that I'm making changes to the bundles that are in the distro, these are ignored. I've tried to get the system to update from the kar, but so far no joy. I'll try also dropping in a JAR for the bundles that I want to update, but this is really quite problematic to develop now and I'm open to suggestions on how to move forward. |
|
IIRC as a workaround I just disabled all suggestion finders in the advanced settings of "Add-on Management" to stop bundles from reverting during development. |
|
IIRC, that is the reverse, you should not disable finders in settings because if disabled some are installed and then uninstalled during OH startup and that triggers the problem. That is what I discovered when analysing the JUPnP issue. |
That's not what it does. If you disable them in the settings and do a restart, they will not get loaded and installed at all the next start. They are not part of a feature that gets started with OH start. These finders are not installed at start of OH, but when the finder service gets started. And this finder service looks for the enabled/disabled configuration. So once disabled, it will not start anymore when you restart OH. You can even disable them before first start in the services config file. The only thing this avoids is the bundle refresh caused by the add-on finders. I remain to be convinced this solves the whole problem (and I do admit the finder installation is one cause of bundle refreshes, so makes the problem worse). Could it be that this issue happens mainly when the distribution addons kar file has been downloaded? It seems to me it picks parts from both the dropped kar file and distribution kar file and mixes them wrongly. Dropping a kar or jar file in the addons folder causes a bundle refresh. And I have the impression it is fairly indeterministic what gets loaded, especially when testing on a snapshot distribution with a snapshot kar dropped in. My guess is it works better with a snapshot kar dropped in a milestone or release distribution (as the snapshot will take precedence). |
|
In my case, tests were done with an offline distribution, that is with a distribution kar file. |
|
Thanks @wborn Disabling the addon management does seem to work around this problem - but only if I use JARs - not KAR. If I use a KAR, the bundles that get loaded are from the distro - not from the new KAR that I put in addons. It's possible that the addon management settings actually make no difference to this and it's just the JARs that are solving the problem, but I don't seem to be able to change the addons settings back - as soon as I now click on these suggestion finder settings to enable them, they now disappear from the UI!!!
|
You need to ensure that “Show Advanced” is checked.. |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: |
|
Is there any way this can be resolved? It's really painful to manage binding development at the moment - at least for the zigbee binding which I have to manually manage about a dozen bundles (the binding bundles of which there are 7 or so, and another 6 or so dependencies. If I use the KAR, it always loads the binding from the addons KAR, or maybe remote repo (I've not tried to work out exactly) rather than the KAR I put in addons. The only way I've currently found to resolve this is to drop the individual JARs into the addons folder. |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/problems-with-shelly-wave-1-mini/160293/23 |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/ikea-tradfri-vindstyrka-no-pm2-5-channel-zigbee/152072/11 |
Using 4.2 snapshot (3808), I encounter a strange behaviour: if I update one bundle (bundle:update) then after a short time (max few minutes), my bundle is automatically restored to its original version ! I encountered that behaviour yesterday after updating either o.o.core.io.transport.mdns or o.o.webui.ui.basic bundles.
What could be the trigger of that behaviour ?
Just to explain the conditions: I just installed the snapshot 3808 form scratch in a new directory. No kar file. Remote add-ons is enabled. I update bundles using bundle:update command.
Earlier I played many hours with release 4.1 and applying many times updates of o.o.webui.ui.basic without encountering that behaviour.
It seems something new in 4.2...
The text was updated successfully, but these errors were encountered: