Fix container images for gladys-z2m-mqtt and gladys-z2m-zigbee2mqtt

[Archive] Feature request
1
  1. Gladys
  2. /server
  3. /services
  4. /zigbee2mqtt
  5. /docker
    /# gladys-z2m-zigbee2mqtt-container.json

{
« name »: « gladys-z2m-zigbee2mqtt »,
« Image »: « koenkk/zigbee2mqtt:latest »,

Just a quick question: shouldn’t we also pin an image here since there don’t seem to be any issues with this one at the moment?

I’m starting to understand how the container part is managed in Gladys’ code :slight_smile: I’m going from plain quiche mode to quiche with bacon :rofl:

except when it breaks what works! :cold_face:
That doesn’t prevent, for example, eclipse-mosquitto from being pinned :wink:

{
« name »: « gladys-z2m-mqtt »,
« Image »: « eclipse-mosquitto:2.0.15 »,

By the way, for now the Node-RED image is currently pinned to 3.1 by @pierre-gilles — that doesn’t mean it won’t evolve, I think!

2

Of course, normally tags like latest or others on Docker Hub are supposed to be validated upstream.
I’m not saying it’s always perfect, but generally when a service goes down, it’s often back up fairly quickly afterwards.
We’ve already had the case with Zigbee2MQTT (Z2M) that crashed and was fixed 20 to 30 minutes later. Usually either you wait for watchtower to do the job, or you pull it yourself.
When that happens, someone always opens a message on the Gladys community and usually an answer is found quickly — either you’re told to wait, or commands are shared for advanced users.

I don’t think it’s worthwhile to lose responsiveness in fixing and evolving external services, knowing that Zigbee2MQTT (Z2M) is in constant development (about one release per month, it seems).
As for services like Mosquitto and Node-RED, that’s debatable, I think..

3

Well yes but @pierre-gilles also takes vacations sometimes and if it happens during that time it could be a disaster until he returns :cold_face: :boom: or else we should provide a way in Gladys to roll back the container to the previous version (hey that’s not a bad idea :thinking:) !

4

One day (watch tower) or a few minutes manually, that’s not too much of an issue I think ^^.

Besides, Gladys 4 is designed so that only the service stops and not

5

For now, the instabilities from Zigbee2mqtt are minor compared to the regular releases, which themselves bring a lot of compatibility (at Z2M, they do 2–3 releases per month depending on the month), so I prefer to keep the current approach to allow everyone to have the latest updates.

If it ever becomes an issue, then why not allow pinning a version.

That could be an idea! However, it’s not really a priority in my opinion right now

2 Likes
6

Well, I wouldn’t have believed that, which goes to show I sometimes come up with good ones :smiley:

7

There could simply be an option to pin between image:latest and image:latest-1 — each time there’s a new image, the current image tag automatically becomes latest-1 and image:latest is loaded.

That way, in case of a crash you can revert to the previous version, and it can also help determine whether it’s a hardware problem or a Gladys problem.

It’s indeed not a priority, but it would make Gladys more reliable with regard to its dependencies, which are the images. :wink:

There are scenarios (alarm, connected door) where a safe environment is required!

With Gladys Plus, you’ll be able to easily connect via a smartphone to change the image when this option is developed, but for users without Gladys Plus it would also be a benefit to pin images via the interface…

8

Hi everyone :slight_smile:

This has been the case for a while, I’m closing this request.