We lost the data volume of a working ExApp because a second Nextcloud instance on the same host uninstalled its own copy of the same app.
Setup: two Nextcloud instances (a real one and a throwaway test instance), each with its own HaRP, both pointing at the same Docker daemon. Container and volume names are built from the app id alone (nc_app_<appid>, nc_app_<appid>_data), so both instances resolved to the same container and the same volume.
Two things happened, and I think both deserve a look:
- Deploying the app on instance B force-removed the running container of instance A and recreated it with B's
APP_SECRET and NEXTCLOUD_URL (DockerActions.php:138 on the HaRP path, :81-88 on the classic one). A's app was broken from that moment, without any warning.
occ app_api:app:unregister <appid> --rm-data on B then deleted the shared volume. For us that was a search index over 50,000 files, roughly 19 hours of rebuild. Docker's own "volume is in use" protection could not help because step 1 had already removed the container that held it.
None of the removal paths checks who created the container or volume: the occ command (Unregister.php:106 and :135-139), the admin UI (ExAppsPageController.php:494-500), and removing a deploy daemon (AppAPIService.php:806/809), which deletes volumes without any flag at all.
I know about #523 and this is deliberately not another naming ticket: even with an instance prefix in place, existing volumes stay unprefixed and the removal paths still delete blindly. It is also not the multitenancy request from nextcloud/HaRP#49, rather the opposite: we do not want to share a container between instances, we want two independent deployments to stop destroying each other.
A fix that would have saved us, and that looks backportable: set labels on container and volume at create time (for example nextcloud.appapi.instance_id) and make the removal paths refuse when the label points to a different instance. Right now the Docker path sets no labels at all, while the Kubernetes path already sets app.kubernetes.io/instance from instance_id (haproxy_agent.py:2374), so the pattern exists in the codebase.
Observed with Nextcloud 34.0.3, AppAPI with HaRP 0.4.5, Docker on Ubuntu (arm64). Happy to share the full logs with timestamps.
We lost the data volume of a working ExApp because a second Nextcloud instance on the same host uninstalled its own copy of the same app.
Setup: two Nextcloud instances (a real one and a throwaway test instance), each with its own HaRP, both pointing at the same Docker daemon. Container and volume names are built from the app id alone (
nc_app_<appid>,nc_app_<appid>_data), so both instances resolved to the same container and the same volume.Two things happened, and I think both deserve a look:
APP_SECRETandNEXTCLOUD_URL(DockerActions.php:138on the HaRP path,:81-88on the classic one). A's app was broken from that moment, without any warning.occ app_api:app:unregister <appid> --rm-dataon B then deleted the shared volume. For us that was a search index over 50,000 files, roughly 19 hours of rebuild. Docker's own "volume is in use" protection could not help because step 1 had already removed the container that held it.None of the removal paths checks who created the container or volume: the occ command (
Unregister.php:106and:135-139), the admin UI (ExAppsPageController.php:494-500), and removing a deploy daemon (AppAPIService.php:806/809), which deletes volumes without any flag at all.I know about #523 and this is deliberately not another naming ticket: even with an instance prefix in place, existing volumes stay unprefixed and the removal paths still delete blindly. It is also not the multitenancy request from nextcloud/HaRP#49, rather the opposite: we do not want to share a container between instances, we want two independent deployments to stop destroying each other.
A fix that would have saved us, and that looks backportable: set labels on container and volume at create time (for example
nextcloud.appapi.instance_id) and make the removal paths refuse when the label points to a different instance. Right now the Docker path sets no labels at all, while the Kubernetes path already setsapp.kubernetes.io/instancefrominstance_id(haproxy_agent.py:2374), so the pattern exists in the codebase.Observed with Nextcloud 34.0.3, AppAPI with HaRP 0.4.5, Docker on Ubuntu (arm64). Happy to share the full logs with timestamps.