-
-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Service to suggest addons based on running processes #3904
Conversation
Signed-off-by: Holger Friedrich <[email protected]>
4c11c65
to
279fcc6
Compare
@holgerfriedrich Nice to see a next step. The easy way to test this is to put an xml file in the userdata/addons folder with the additional discovery content. Any xml file with valid content will be picked up from there. So there is no need to do a full build. A few questions and remarks I have:
|
...rocess/src/main/java/org/openhab/core/config/discovery/addon/process/ProcessAddonFinder.java
Outdated
Show resolved
Hide resolved
I would prefer to have the same mechanism in place for all the discoveries. Having processes scanned in the background might not be something everybody wants. |
The PR is it is does not cache the running processes anywhere, so there is no background scanning. It will just make a call to get the processes when called from the suggestions REST endpoint. In the UI that means: when running the setup wizard or when opening the addon store. We can of course allow to disable that call as well. The main reason to be able to enable/disable was to avoid having all UPnP/mDNS dependencies loaded and running in the background only for addon discovery. As there is no extra dependency here, and as long as there is no scheduled scan and result caching, I don't see the point. But of course, see my concern about caching. If it is required, I think this becomes a different discussion. |
Yes, that's why I was assuming that the logic of the PR will be changed to do some background scanning in future. |
I am glad to hear that :) the match-property model should suit most kinds of finder. |
None really. It crosses over from addons to core so the only way to test is a full distro. |
@andrewfg @holgerfriedrich I think this is the easy way to test without a full build. You can test in the IDE. |
Signed-off-by: Holger Friedrich <[email protected]>
Signed-off-by: Holger Friedrich <[email protected]>
Signed-off-by: Holger Friedrich <[email protected]>
Signed-off-by: Holger Friedrich <[email protected]>
de5e398
to
20fd530
Compare
Thank you all for the comments. I finally got it working for knxd.....
I will create a corresponding PR in addons repo. The finder allows to specify multiple patterns. I did not manage yet to test without building a distro package. Still not sure how to do core development with Visual Studio Code. For now, it is without caching and background scanning. |
Both this PR and PR in addons repo ready for review. The UI (add-on store) shows suggestions only for bindings. The wizard picks up all suggested add-ons. |
PR openhab/openhab-webui#2213 created to solve this. |
...covery.addon/src/main/java/org/openhab/core/config/discovery/addon/AddonFinderConstants.java
Outdated
Show resolved
Hide resolved
...covery.addon/src/main/java/org/openhab/core/config/discovery/addon/AddonFinderConstants.java
Outdated
Show resolved
Hide resolved
@@ -83,6 +83,12 @@ | |||
<feature dependency="true">openhab.tp-jmdns</feature> | |||
</feature> | |||
|
|||
<feature name="openhab-core-config-discovery-addon-process" version="${project.version}"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you add this feature to openhab-runtime-base
you will not need to add this finder to the constants in AddonFinderConstants.java. The feature will then automatically get installed and not through the service. The only reason to do it through the service is to allow enabling/disabling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think someone did already ask to have enabling/disabling. ??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me, that's conditional. If retrieving the processes is too high a load, we should. Otherwise I don't see the point. Right now, the implementation does not cache anything and does a call to retrieve the processes any time the suggestions are retrieved. If that is quick, no need to enable/disable a little piece of code. There is nothing running in the background in separate threads either.
@kaikreuzer Did not react on my feedback on it. If he feels strongly, then, of course it needs to be there, but it should also be added to the configuration parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mherwege I am OK with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done as suggested, just did the verification - still works
|
||
private static final String COMMAND = "command"; | ||
|
||
public static final String SERVICE_TYPE = SERVICE_TYPE_PROCESS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can eliminate these constants from AddonFinderConstants.java and define them here instead with the same logic. Only refer to ADDON_SUGGESTION_FINDER in AddonFinderConstants.java.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...but I had to make ADDON_SUGGESTION_FINDER public...
...rocess/src/main/java/org/openhab/core/config/discovery/addon/process/ProcessAddonFinder.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Holger Friedrich <[email protected]>
LGTM |
@holgerfriedrich just for the avoidance of doubt: di you adapt to the new addon.xml schema? |
There is no impact of the new format for this PR. There are no discovery parameters. So no reason to wait if a maintainer agrees. |
@holgerfriedrich the whole point of the revised schema is because you mis-used the match-properties as if they would be discovery-parameters. Therefore you need to change your mis-used properties to parameters instead. @mherwege for info.. |
Oops! Sorry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks!
...rocess/src/main/java/org/openhab/core/config/discovery/addon/process/ProcessAddonFinder.java
Outdated
Show resolved
Hide resolved
…in/java/org/openhab/core/config/discovery/addon/process/ProcessAddonFinder.java Signed-off-by: Kai Kreuzer <[email protected]>
@holgerfriedrich I just tried the latest distro snapshot (3787) and see this log during startup:
Any idea why this happens? |
Hm, I have an idea: My version of the file is from Dec 10, i.e. it wasn't overwritten during the update. We will need to fix this, but it isn't relevant for the milestone release as the file didn't exist in the previous milestone. |
@kaikreuzer this happened before when the schema was adapted. I think we have to improve logging in the addon info provider.
This is good. In case of parser failure, all of the suggestions finders won't work. May it be a problem for users of the daily snapshots? - then we should create a new issue.... |
@holgerfriedrich / @kaikreuzer / @mherwege - we changed the schema between two snapshots; so perhaps the new snapshot failed (correctly) to parse an addons.xml file from a prior snapshot based on the prior schema. Therefore I think that in the final build this will probably have all reconciled again. => But please do check before the final final release! |
A few things..
So I think that once everything has synchronized between the build processes of openhab-core and openhab-addons then the problem should have been resolved.. |
The file is in the userdata folder. Does it get deleted and recreated with an upgrade? If not we need to make sure this is done? |
As mentioned above: "it wasn't overwritten during the update." So yes, it is an issue for anyone using snapshot updates and it will be a problem in future for anyone else. So we need to fix this. |
I don’t know how the installation and upgrades work exactly. @J-N-K can you help with this? Is it something to be done in the distro? Should the file go somewhere else to be removed and recreated in an upgrade? The code in core only takes care of reading the file that is there. |
For the avoidance of doubt..
What other scenarios are we dealing with than the above? |
This file should always be overwritten, as it will contain the latest info when upgrading. The issue is here: https://github.com/openhab/openhab-distro/blob/3721abe2ed8ec20134db021e33ef3fc5d6c3164d/features/distro/src/main/feature/feature.xml#L13 override should be true to force an overwrite. I am not behind a computer now, so tough to create a PR, but it should be done to correct this. |
I guess there are several solutions:
I would probably vote for the last one, then it SHOULD be recreated when you clear the cache (which especially for snapshots might be an issue otherwise). |
Or (even better) do it like @mherwege suggests. |
@holgerfriedrich I have a couple of (admittedly very late) questions concerning this finder resp. PR..
|
@andrewfg I use Java to obtain a list of processes, see https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/ProcessHandle.html#allProcesses() I tested with Linux and Windows. The trace output which dumps the process list got removed in one of the last commits. |
So to answer (some of) my own questions:
Therefore I will shortly create a new PR to improve this finder so that it can discover addons that depend on running services and/or scripts.. |
@andrewfg Ok, for sure this is not working with script processors. Until now, only the main executable can be matched. Are you going to add a new match property for arguments or do you want to extend the command to the full command line? For the latter one we would have to change existing descriptions for example from |
I am thinking of keeping the existing property NEVERTHELESS I note that your existing code may take |
This is a first draft of a new finder to suggest addons based on the software running on the OH server.
It checks the process list and tries to detect known software.
It has been mentioned in
#3868 (comment)
It will require changes in the
addon.xml
of the binding as well, but no change to the xsd, as the givenmatch-property
is reused. Here an example for influxdb.@andrewfg Maybe you can have a short look if I forgot something before I try to create a full distro package to test it.
Any recommendation on how to test in a simpler way would be very welcome....