Deploy and unregister --rm-data silently destroy another instance's ExApp container and volume when two Nextclouds share one Docker daemon
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 65/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- docker, kubernetes, php
- 領域
- devops, infrastructure
調査の方向性
DockerActions.php:138 と :81-88 から始め、次に Unregister.php:106 と :135-139、ExAppsPageController.php:494-500、AppAPIService.php:806/809 の削除パスを調査します。これらのパスを haproxy_agent.py:2374 のインスタンスラベル処理と比較します。Docker コンテナとボリュームがインスタンス識別情報を持ち、削除処理が別のインスタンスに属するリソースの削除を拒否しつつ、同じインスタンスのクリーンアップを維持できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- PHP
- スター
- 198
- フォーク
- 26
- 平均マージ
- 2日 6時間
- マージ済み PR（30日）
- 48
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
nextcloud/app_api のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 3 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
nextcloud/app_api#1099 · コメント 1 件 ·
メンテナーはふだん 3 日以内に返信
-
deploy discussion enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
メンテナーはふだん 3 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
nextcloud/app_api#1013 · コメント 2 件 ·
メンテナーはふだん 3 日以内に返信
-
daemon enhancement
難易度 3/5 1〜2日 初心者へのやさしさ 52/100
メンテナーはふだん 3 日以内に返信
nextcloud/app_api の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
scanaislop/aislop#482 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
humanmade/publication-checklist#73 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
Werkstattl/OpenBlogware#92 ·