Hi!
I have been using iotstack for a couple years successfully. Thanks for
this 🙂 Yesterday after doing an "update all containers", I found that
the homeassistant websocket was not installed in node-RED. I tried
removing it in the container options and installing it in node red
afterwards, and then got this error. Can it be true that node-RED is
not up to date anymore? Can I fix this with iotstack menu?
2023-10-29T14:51:12.235Z [err] ERR! notsup Unsupported engine for node-red-contrib-home-assistant-websocket@0.57.4: wanted: {"node":">=14.0.0"} (current: {"node":"12.22.8","npm":"6.14.15"})
This is an extract of the relevant function:
$ grep -A 16 "def updateAllContainers()" ~/IOTstack/scripts/docker_commands.py | grep -v "print"
def updateAllContainers():
subprocess.call("docker-compose down", shell=True)
subprocess.call("docker-compose pull", shell=True)
subprocess.call("docker-compose build", shell=True)
subprocess.call("docker-compose up -d", shell=True)
input("Process terminated. Press [Enter] to show menu and continue.")
needsRender = 1
return True
There are several problems with this command sequence:
There is no need to down the stack while downloading images and/or rebuilding containers is occurring.
The pull command is correct. It deals with service definitions containing image: clauses, queries DockerHub for updates, and downloads any more-recent images it finds.
The build command is incorrect because it simply re-runs Dockerfiles on top of already-downloaded base images to produce new local images. In its current form, this command will never query DockerHub to download a more-recent base image. This command needs to be expressed as:
docker-compose build --no-cache --pull
The "up" command is correct. When issued, any newly-downloaded (by the pull) or newly-rebuilt (by the build) images will be instantiated as running containers, with new-for-old container swaps occurring at the last moment, resulting in negligible downtime.
There is also a command missing from the sequence, which is:
docker system prune -f
That cleans up old local images and build artifacts.
The absence of the --no-cache --pull flags from the build command is the direct cause of the problem reported on Discord:
The old base image for Node-RED was retained.
The Dockerfile was re-run.
The Dockerfile run caused updated versions of the add-on nodes to be downloaded.
The node-red-contrib-home-assistant-websocket node required version of Node-RED 14 while only version 12 was available - because the build had not forced an up-to-date base image.
The following post appeared on Discord:
This is an extract of the relevant function:
There are several problems with this command sequence:
There is no need to down the stack while downloading images and/or rebuilding containers is occurring.
The
pull
command is correct. It deals with service definitions containingimage:
clauses, queries DockerHub for updates, and downloads any more-recent images it finds.The
build
command is incorrect because it simply re-runs Dockerfiles on top of already-downloaded base images to produce new local images. In its current form, this command will never query DockerHub to download a more-recent base image. This command needs to be expressed as:The "up" command is correct. When issued, any newly-downloaded (by the
pull
) or newly-rebuilt (by thebuild
) images will be instantiated as running containers, with new-for-old container swaps occurring at the last moment, resulting in negligible downtime.There is also a command missing from the sequence, which is:
That cleans up old local images and build artifacts.
The absence of the
--no-cache --pull
flags from thebuild
command is the direct cause of the problem reported on Discord:The old base image for Node-RED was retained.
The Dockerfile was re-run.
The Dockerfile run caused updated versions of the add-on nodes to be downloaded.
The
node-red-contrib-home-assistant-websocket
node required version of Node-RED 14 while only version 12 was available - because thebuild
had not forced an up-to-date base image.