AIO and HARP for ExApp running remotely

[knot-split]

When the aio-harp is fixed, will I be able to run an exapp (e.g. context chat backend) on another computer in my LAN instead of where my Nextcloud-AIO is running? The other computer has bling-bling GPU, so I’d like to channel AI operations to that instead of NC machine. I’ve been studying the docs on HARP, ExApp, CCB, and forum discussions for weeks, but I haven’t succeeded in getting anything that seems to work.

[szaimen]

Hi, for this kind of setup you need to configure harp and app_api manually. Here a link to the general docs: AppAPI and External Apps — Nextcloud latest Administration Manual latest documentation

[knot-split]

so “manually” probably means that when I register a daemon from the app API gui, I should choose something that says manual install rather than docker install.

here is as far as I got so far: I have the context chat backend running on the remote machine, and it is talking to the harp container running on the nextcloud machine. I have a harp daemon, which is passing the test-deploy, and making use of the same harp-api instance. The daemon was registered as a docker-install type. Perhaps this is the reason why I can’t get NC to recognize the remote instance of the backend. It always tries to install a new instance on the NC machine.

The deployment docs give a few instances, in particular, one for using the AIO, and another for having a remote external app, but it does not give one for using the AIO along with a remote external app. The two cases have conflicting instructions, so it is hard to try to merge them together. It shows that external apps would still find a place within the master container stack, but they cannot be here if they are on remote machines.

Perhaps the solution is to change the harp daemon to a type of manual install, and then perhaps next cloud wouldn’t be inclined to install its own second instance of the backend every time I try to register the existing one.

The backend chat manual install gives this registration:

occ app_api:app:register context_chat_backend manual_install --json-info
“{“appid”:“context_chat_backend”,“name”:“Context Chat Backend”,“daemon_config_name”:“manual_install”,“version”:“5.3.0”,“secret”:“12345”,“port”:10034,“scopes”:,“system_app”:0}”
–force-scopes --wait-finish

at this point, my guess is that if the demon is flagged as manual install, and the context backend is already running with the harp API acknowledging it, then somehow this register command will use what the harp API container knows about the pre-existing backend.

this is the one last thing that I have yet to try.

[knot-split]

So I eventually figured this out. Using the manual install was absolutely correct. I can set up a harp container on my fileserver but outside of my next cloud container. I got the context chat back and up and running on a separate machine that has a fast GPU. Then from the OCC command line, I would issue a command to enable and register a demon and the app. So when you’ve chosen manual install the next cloud knows not to download a copy of the app and knows not to put it on to your file server, but rather expects that you set it up yourself somewhere else and you just have to tell it where it is. So I got this working and I got everything talking.