Utilisation des images docker en mode latest

Hello :wave:

L’image Zigbee2Mqtt a été mise à jour il y a quelques heures et mon watchtower a bien fait le travail :slight_smile:

Malheureusement, la version 1.19.0 a un souci (voir ici : NPM crashes on Raspberry Pi 3 B+ in the latest Docker image · Issue #7662 · Koenkk/zigbee2mqtt · GitHub)

Est-ce qu’il faut arrêter d’utiliser les images en mode latest ? Mais dans ce cas-là, comment les mettre à jour ?
Ou faut-il prendre ça comme un problème qui arrive rarement (et qui sera corrigé rapidement je pense) ?

1 Like

Version spécifique

Mais ça implique de tester et gérer les updates

Ça va être fix rapidement je penses

Je ne sais pas justement comment gérer les mises à jour. Ça nécessite de gérer un système de recréation/update de containers et c’est pas évident.

On peut pas y faire grand chose. Ça arrive

Faut surveiller l’évolution côté z2m et communiquer.

1 Like

Regarde ce qu’on a fait dans l’intégration MQTT ! On a fixé la version et on a un mécanisme de mise à jour en place. Au démarrage de Gladys, on vérifie la version du container et on le met à jour si besoin :slight_smile:

Y’a pas de tag stable ou version majeure chez z2m

Je vois deux solutions :

  1. On laisse le tag latest et il faudra communiquer en cas de bug de ce type.

  2. On fixe une version “approuvée” dans le service Zigbee2Mqtt, qui est réévaluée à chaque nouvelle release de Gladys. Cela implique que nous devons faire le test de la dernière version z2m disponible et si elle est fonctionnelle, mettre à jour le service Zigbee2Mqtt pour la recréation du conteneur au démarrage de Gladys.

Je suis d’accord avec @lmilcent en sachant que la 2 est quasi impossible ( on manque tous de temps)

Je préfère avoir une version stable même si ça signifie passer un peu de temps pour tester les images ET ne pas bénéficier des dernières nouveautés le jour même.
Je vais regarder ce qui est fait sur Mqtt.

Pour la validation des nouvelles versions ça peut être fait assez rapidement.

  1. On identifie ceux qui utilisent Z2M et quelle adaptateur USB ils ont
  2. En cas de nouvelle version, chacun utilise la version de dev et valide le bon fonctionnement avec ses capteurs

En une semaine max c’est fait, et sans se casser trop la tête, on évite les bugs rencontré hier avec un conteneur qui se lance plus.

Après au final, dans tous les cas qu’on utilise une version major/minor ou une version latest, le problème aurait été le même dans le bug qu’on a vu l’autre jour: si les mecs de chez Zigbee2mqtt poussent une version cassée sur le tag qu’on utilise (quel qu’il soit), ça cassera chez nous.

Contrairement à NPM, un tag Docker n’est pas garant d’immutabilité, on peut pousser une image cassée sur un tag existant, cassant donc l’existant.

C’est le problème des intégrations avec des third-party, on est totalement dépendant des third-party, et on peut pas faire grand chose là dessus! :slight_smile:

Je suis d’accord dans l’idée, après dans la pratique on arrivera jamais à avoir la vélocité de leur projet dans Gladys, en tout cas pas actuellement, il n’y a pas assez de contributeurs/volontaires qui contribuent sur Gladys pour faire des review fréquentes. En tout cas moi sur tous les builds dev que je fais, je n’ai jamais de testeurs.

Pour donner un exemple, dans le cas du Z-Wave, on a mis une version fixée pour éviter ces problèmes, et la version est mise à jour tous les an au mieux.