Juste une petite interrogation : Est-ce qu’il ne faudrait pas là aussi fixer une image vu qu’il ne sembles pas y avoir de problèmes actuellement avec celle-ci ?
je commence a comprendre comment est géré dans le code de Gladys la partie container je passe du mode quiche tout court à quiche avec des lardons
sauf quand ca casse ce qui marches !
Ca empeches pas par exemple eclipse-mosquitto est fixé
Bien sur, après normalement les tags comme latest ou autre dans docker hub sont sensé être validé en amont.
Je ne dit pas que c’est tjrs parfait mais en général quand un service tombe, il est souvent up assez rapidement derriere.
on a déjà eu le cas avec Z2M qui a déjà crash et fixé 20 à 30 min après. En général soit tu attends que watchtower fasse le taff, soit tu fais la pull toi même.
Quand sa arrive, il y a tjrs quelqu’un qui ouvre un message sur le community de Gladys et en général la réponse est vite trouvé et soit il est dit d’attendre, soit les commandes sont communiqué pour les utilisateurs avancés.
Je ne pense pas qu’il soit intéressant de perdre de la réactivité dans les fix et evolution de service externe, sachant que Z2M est en constante évolution (1 release par moi il me semble).
Après pour les services tel que mosquitto et node red cela se discute je pense…
Bah oui mais @pierre-gilles prends aussi des vacances des fois et si cela tombes pendant ce temps cela risque d’être la cata jusqu’à son retour ou alors il faudrait prévoir une possibilité dans Gladys de revenir à la version précédente du container (tiens c’est pas bête cela ) !
1 journée (watch tower) ou quelques minutes manuellement c’est pas trop gênant je pense ^^.
Après Gladys 4 est faite de manière a ce que seul le service stop et pas toutes ta domotique. donc a voir ce que vous déciderez mais depuis que le service Z2M est intégré, il n’y a eu qu’un échec corrigé le lendemain donc cela ne me choque pas perso.
Pourquoi ne pas laisser le choix comme a l’époque de la V3 avec un select sur quelques tag présélectionné par l’intégrateur (bon il me semble que @pierre-gilles sera contre cette idée car il préfère un outil clef en main et facile d’utilisation pour n’importe qui)
Pour l’instant, les instabilités de la part de Zigbee2mqtt sont anecdotiques par rapport aux releases régulières qui elles apportent de nombreuses compatibilités (Chez Z2M, ils font 2-3 releases par mois selon les mois), donc je préfère garder l’approche actuelle pour justement permettre à tous d’avoir les dernières maj.
Si jamais ça devient un souci, alors pourquoi pas permettre de fixer une version.
Pour le coup ça peut être une idée ! Après, c’est pas vraiment une priorité à mon sens actuellement
il pourrait simplement y avoir le choix de fixer entre image:latest et image:latest -1, à chaque fois qu’il y a une nouvelle image le numéro de l’image en cours devient automatiquement latest-1 et l’image:latest est chargée.
Comme cela en cas de crash on peut revenir à la version précédente et cela peut aussi servir à discriminer un problème matériel ou gladys.
C’est effectivement pas une priorité mais cela fiabilisera le fonctionnement de gladys vis à vis de ces dépendances que sont les images.
Il y a des cas de figures (alarme, porte connectée) ou il faut un environnement sûr !
Avec Gladys plus, on pourra aisément se connecter via un smartphone pour changer l’image quand cette option sera developpée mais pour les utilisateurs sans gladys plus ce sera aussi un plus de fixer les images via l’interface…
je passe du mode quiche tout court à quiche avec des lardons 
ou alors il faudrait prévoir une possibilité dans Gladys de revenir à la version précédente du container (tiens c’est pas bête cela 
) !