occ command to update an existing deploy daemon (app_api:daemon:update) #1129

Describe why it is important and where it will be useful

There is no occ command to change the settings of a deploy daemon that is already registered, such as its HaRP address, FRP address, shared key, Docker network, Nextcloud URL or compute device. Neither of the existing commands can be used for it:

• Running app_api:daemon:register again with the new settings does nothing. It skips a name that already exists ("Registration skipped, as the daemon config … already exists.") and returns 0.
• Running app_api:daemon:unregister first, to register it again, fails once ExApps are deployed on the daemon ("Error: … daemon contains N ExApps, please remove them first to proceed.").

So once ExApps are deployed, the only way to change a daemon is the admin settings UI. Anything that manages Nextcloud with occ (provisioning scripts, configuration management, container startup hooks) cannot keep a daemon's settings up to date.

Unregister + register also drops anything else stored on the daemon, for example the Docker registry mappings added with app_api:daemon:registry:add.

The ability already exists in AppAPI: DaemonConfigService::updateDaemonConfig() updates a daemon in place, and the admin settings use it through DaemonConfigController::updateDaemonConfig. It is just not reachable from occ.

Describe your proposed solution

A new command, app_api:daemon:update, taking the same arguments and options as app_api:daemon:register:

occ app_api:daemon:update harp_proxy_docker "Harp Proxy (Docker)" "docker-install" "http" "appapi-harp:8780" "http://nextcloud.local" \
  --net nextcloud --harp --harp_frp_address "appapi-harp:8782" --harp_shared_key "<key>" --compute_device=cuda

It would:

1. Fail if the daemon does not exist.
2. Validate the input and build the deploy config exactly like register does (the same checks, buildComputeDevice, validateNewSecret, encrypting the shared key).
3. Update the existing row in place with updateDaemonConfig(), keeping the id and the name, so deployed ExApps stay attached.
4. Keep deploy config keys that the command does not manage, such as registries.
5. Honour --set-default like register does.

The option handling could be shared between the two commands, so they cannot drift apart.

An alternative with the same effect would be an --update (or --force) flag on app_api:daemon:register that updates the daemon instead of skipping when the name already exists. That would also make register usable as a single idempotent command.

Describe alternatives you've considered, if relevant

• Unregister + register: not possible while ExApps are deployed, and it loses the registry mappings.
• Editing oc_ex_apps_daemons directly with SQL: the shared key must be encrypted with Nextcloud's crypto, the deploy config layout is internal, and it has to work on every supported database.
• The admin settings HTTP endpoint: needs admin credentials and password confirmation, so it does not fit non-interactive use.
• A PHP script calling DaemonConfigService::updateDaemonConfig(): works, but depends on AppAPI internals that are not a public interface.

Additional context

Code references (current main):

• lib/Command/Daemon/RegisterDaemon.php: skips an existing name.
• lib/Command/Daemon/UnregisterDaemon.php: refuses when ExApps are deployed.
• lib/Service/DaemonConfigService.php: updateDaemonConfig().
• lib/Controller/DaemonConfigController.php: updateDaemonConfig(), used by the admin settings.