Deploy and unregister --rm-data silently destroy another instance's ExApp container and volume when two Nextclouds share one Docker daemon
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 65/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- docker, kubernetes, php
- Área
- devops, infrastructure
Línea de trabajo
Comienza con DockerActions.php:138 y :81-88; después, inspecciona las rutas de eliminación en Unregister.php:106 y :135-139, ExAppsPageController.php:494-500 y AppAPIService.php:806/809. Compara estas rutas con el manejo de la etiqueta de instancia en haproxy_agent.py:2374. El trabajo estará terminado cuando los contenedores y volúmenes de Docker lleven una identidad de instancia y la eliminación se niegue a borrar recursos pertenecientes a otra instancia, manteniendo la limpieza de la misma instancia.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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_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: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.
- Lenguaje dominante
- PHP
- Estrellas
- 199
- Forks
- 26
- Merge medio
- 2 d 6 h
- PR fusionados (30 d)
- 48
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de nextcloud/app_api
-
Daemon delete dialog: "Remove all ExApps" checkbox and `removeExApps` parameter have no effectAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 3 días
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
nextcloud/app_api#1099 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
deploy discussion enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
Los mantenedores suelen responder en 3 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
nextcloud/app_api#1013 · 2 comentarios ·
Los mantenedores suelen responder en 3 días
-
daemon enhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 3 días
Todos los issues de nextcloud/app_api
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
TYPO3BestPractices/tea#2409 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
api-platform/core#8690 ·
Los mantenedores suelen responder en 1 día
-
No Code Attached Yet
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
joomla/joomla-cms#48626 ·
Los mantenedores suelen responder en 1 día
-
enhancement good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
DorsetDigital/silverstripe-schema-manager#26 ·
Los mantenedores suelen responder en 1 día
-
sync-en
Dificultad 1/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 4 días