Delete pad after delay
Hello! J'aimerais bien une relecture, surtout de la part des admins actuels. Je doute surtout du fait que ma nouvelle version du docker-compose ne casse pas la prod (conservation des noms de volumes etc). J'ai tout vérifié mais on n'est jamais trop sûrs ;)
Au passage, j'ai aussi:
- accéléré la compilation de l'image en fixant les pb de chown
- bougé la variable d'environnement de Abiword dans le dockerfile, puisque c'est le dockerfile qui contrôle le path (actuellement c'est le fait qu'on utilise debian/apt qui détermine l'endroit où sera installé abiword). Mais ça reste une variable d'environnement, qui peut être overridée dans le docker-compose si nécessaire.
- normalisé les noms là où c'était possible (j'espère ne pas avoir touché aux noms réels des volumes)
@qduchemi je t'assigne de façon totalement arbitraire, hésite pas à refiler le bébé à quelqu'un d'autre, J'EN APPELLE AU DISCERNEMENT DE CHACUN
Merge request reports
Activity
added 1 commit
- a963fea9 - moved ABIWORD env from d-c.yml to dockerfile
added 13 commits
-
a963fea9...80f9b363 - 12 commits from branch
master - 95637296 - Merge branch 'master' of gitlab.utc.fr:picasoft/projets/dockerfiles into delete-pad-after-delay
-
a963fea9...80f9b363 - 12 commits from branch
added 1 commit
- e8106ca0 - Deactivate deletion loop in Etherpad, because now we use an external script
- Resolved by Quentin Duchemin
Pas encore testé mais à valider vite fait @rmaliach
Mais top sinon ! :D Ça vaut peut être le coup d'ajouter un peu de doc ou un lien vers le README
dockersur le fork du plugin (HS sur cette PR), pour faciliter la compréhension - Last reply by Quentin Duchemin
89 88 - standard_dpad-app 90 89 depends_on: 91 90 - standard_db 91 - standard_delete-pad-after-delay -
@qduchemi Mauvaise idée, mon container refuse de démarrer (il tourne sur une boucle de requêtage de app avec un timeout et un délai) tant que app a pas démarré. Alors OUI ça marche parce que dans les fait app met tellement de temps à démarrer que dpad a largement le temps. Mais si jamais un jour etherpad était plus rapide ça marcherait plus.
Je vois pas le souci, tout ce que fait cette clause c'est de faire démarrer ton conteneur lorsqu'on fait un
docker-compose up -d standard_app, ce qui est plutôt bien parce que sinon on doit fairedocker-compose up -d standard_app standard_delete-pad-after-delay.Et en effet, ton conteneur sera lancé en premier, il failera sur sa première itération, mais ensuite ça le fait, non ?
-
Si on est réaliste sur la durée de boot d'etherpad et qu'on fournit à mon conteneur les paramètres de retry kivonbien, alors ça marche.
D'un point de vue sémantique, ça me chiffonne, parce que dpad est le client et app est le serveur; et app peut très bien tourner toute seule (alors que dpad fail si app ne tourne pas). Donc en lisant ce docker-compose, on peut ne pas comprendre.
Cependant, j'entends bien ton argument: c'est une "sécurité" qui permet de lancer automatiquement dpad même si l'utilisateur a demandé de lancer seulement app. Mais j'ai envie de dire que cet utilisateur a bien cherché la merde - ou plutôt, que ça me paraît assez peu irréaliste que, au lieu de taper
dc upil ouvre le dc, regarde les noms des conteneurs, et ne décide de lancer que app.Ce à quoi tu pourrais me répondre: oui, mais il pourrait retrouver le nom du conteneur en faisant un
docker ps, puis il pourrait arrêter toute la prod avec undc downet remonter uniquement le mauvais conteneur.Déjà, non, parce que les noms réels des conteneurs (spécifiés avec
container_namesont différents des noms manipulés par docker-compose, donc ça veut dire qu'il va un minimum se casser la tête (en l'occurrence virer le préfixeetherpad_, ok, il va peut-être y arriver).Et surtout, est-ce que ce serait si grave? Si quelqu'un oublie de lancer dpad? Pas sûr.
Ma position (qui est contestable) c'est qu'il vaut mieux écrire quelque chose de lisible plutôt que quelque chose de pas lisible quand les deux marchent.
Ma position est contestable, et je te demande ton avis, parce que j'oublie cette "sécurité" au cas où quelqu'un oublierait de lancer dpad, mais je considère que c'est pas grave, parce que:
- je considère qu'il y a peu de chances que ça arrive, ou
- que ça aura peu de conséquences, ou
- que quelqu'un se rendra vite compte qu'on a oublié de lancer ce conteneur. Mais peut-être que je sur-estime la team technique sur ces trois points. Qu'en penses-tu?
que quelqu'un se rendra vite compte qu'on a oublié de lancer ce conteneur
Pour le coup, c'est assez peu probable.
En revanche, je te rejoins sur la sémantique, et je n'y avais pas pensé. L'application ne dépend pas techniquement de
dapp, même si son fonctionnement nominal en dépend. Mais c'est mieux dans l'autre sens.En fait, ça fait un moment que ça me chiffonne (et c'est de mon fait), mais que les
weeketstandardcohabitent au sein du même fichier Compose, c'est moche. À la base, il me semblait que c'était cohérent, mais ce sont deux services différents.Etherpad est donc une exception vis-à-vis de la doc où on ne peut pas lancer un
docker-compose up -dsur la prod sans démarrer les deux instances.Je viens de me rappeler pourquoi j'ai fait ça : à l'époque il y avait la CI, et elle exigeait un fichier Compose à la racine
Donc il me semble qu'une solution serait la suivante :
- Séparer les instances dans deux fichiers séparés (mais très similaires, ce qui n'est pas grave, car on peut supposer que ces fichiers évoluent indépendamment)
- Rétablir le
depends_ondedappversapp
C'est moins le bordel, la sémantique est correcte (même si en vrai
depends_onc'est bien pourri, genre undocker-compose up -d --force-recreaterecrée toutes les dépendances, je trouve que c'est pas du tout attendu...) et undocker-compose up -dstandard ne fout pas la merde. Qu'en penses-tu ?
que quelqu'un se rendra vite compte qu'on a oublié de lancer ce conteneur
Pour le coup, c'est assez peu probable.
En revanche, je te rejoins sur la sémantique, et je n'y avais pas pensé. L'application ne dépend pas techniquement de
dapp, même si son fonctionnement nominal en dépend. Mais c'est mieux dans l'autre sens.En fait, ça fait un moment que ça me chiffonne (et c'est de mon fait), mais que les
weeketstandardcohabitent au sein du même fichier Compose, c'est moche. À la base, il me semblait que c'était cohérent, mais ce sont deux services différents.Etherpad est donc une exception vis-à-vis de la doc où on ne peut pas lancer un
docker-compose up -dsur la prod sans démarrer les deux instances.Je viens de me rappeler pourquoi j'ai fait ça : à l'époque il y avait la CI, et elle exigeait un fichier Compose à la racine
Donc il me semble qu'une solution serait la suivante :
- Séparer les instances dans deux fichiers séparés (mais très similaires, ce qui n'est pas grave, car on peut supposer que ces fichiers évoluent indépendamment)
- Rétablir le
depends_ondedappversapp
C'est moins le bordel, la sémantique est correcte (même si en vrai
depends_onc'est bien pourri, genre undocker-compose up -d --force-recreaterecrée toutes les dépendances, je trouve que c'est pas du tout attendu...) et undocker-compose up -dstandard ne fout pas la merde. Qu'en penses-tu ?Edited by Quentin Ducheminadded 1 commit
- 2560e21f - [docker_test.sh] Remove useless error message
added 1 commit
- 8a076e1c - [docker_test.sh] Repeat after me : 'never code again'
added 1 commit
- db678182 - [Etherpad] Fix comment being included in environment variable
added 1 commit
- bbb2d39e - [Etherpad] Bump script for deletion and remove deleted pads creation from Etherpad
added 1 commit
- 33ad4f3a - [Etherpad] Fix name of dpad for week instance
mentioned in commit 3fc210ca