Offical Upgrade Guide for Node Red?

As I said, we had this page before and it was full of if/but/maybes because there are so many different ways users might have installed everything to begin with. And it was a common source of confusion.

There are so many ways a user may have installed Node.js, we simply cannot enumerate all of the different ways that might be right for them to upgrade.

That is why we, if I can be so bold, approach this as best practice type of thing, not with an explicit detailed procedure.

For example:

WHAT TO DO BEFORE UPGRADE

  1. Backup flows file to a safe location. Suggested backup is to different media than where node-red is at present, a different disk, SD card, etc. At a minimum copy the .node-red/.flows*.json.backup and flows*.json files.

  2. Upgrade in place of node-red may or may not update npm and node.js. So if other applications or solutions on the same device/system use node.js, use the upgrade script with caution.

  3. Document the node modules that are installed, this information may be needed in the event that the upgrade in place encounters unexpected or unforeseen issues. Refer to the command 'npm list' for additional details.

  4. It is recommended that on initial restart of the node red after upgrade is done with the --safe option, to ensure that all flows are present as expected, and any automatic flow execution is not done by default until validated on just installed version of node red.

Note: Some environments may have unique requirements or qualifications, such as, processor architecture dependencies, specific to the existing node.js installation. For example, upgrade in place will not update node.js to ARM v7 binaries if ARM v6 binaries are already present, regardless of the processor architecture present.

Yes this is a bit generic, but it covers a lot of ground, that right now, is not covered, no? And this is just off the top of my mind, so I am sure it needs some word smith effort. As a newer node-red enthusiast, such a section or page in the official documentation would have been well received. Answered a few questions I posted to the forum as well.

On the Getting Started page there are nine ways to get started. The upgrading page might effectively be a repeat of that page saying to find the upgrade instructions there, for each of the installation methods.

I think I meant little more than a link to our existing instructions, which are on the Supported Node Versions page. I think that page does not have the best title.

For a page in the FAQ section titled 'what version's of node are supported' then the title is ideal.

Does my reply above not serve as a possible way to tackle this issue?

It is a possible way. But it doesn't cover all the ground that needs to be covered. It assumes there is a script to run. That is only true if you installed using the script, which only applies for Pis (or ubuntu/deb based systems).

If you're running on IBM Cloud or with docker or with a local npm install or with a global npm install the upgrade path is entirely different.

Having a page around backing up flows would be a good addition. Again, it was information on the old how to upgrade page that got lost when we split it out to the individual pages for different platforms.

I think upgrading and backup are two different topics, and while doing a backup at upgrade time is valid there should be no necessity to do so (on this Pi/debian thread anyway) - as a) the script does not touch your flows files b) if an LTS version of nodejs is installed again the script doesn't touch it - the usual sudo apt upgrade may but that's BAU. c) the generated package.json file in the user directory is effectively a list of extra nodes installed and d) the --safe option was self inflicted by yourself modifying flows - and not the upgrade process so no need for it to be the recommended course of action.

But yes I agree a doc on (what to) backup, and how they could be useful for a) recovery and b) migration to another machine would be useful ( to cover flow names, arm6/7, creds files etc)

1 Like

@knolleary
Yes, my Pi bias is there :slight_smile:

@dceejay
I disagree, a backup is always a best practice before any type of upgrade in place. That is my enterprise IT experience history chiming in. You never know what or when something will go sideways. Even if the script (Pi bias again) never touches the flow files. That is not the scope or goal of recommending the backup before upgrade, it is to avoid the unexpected.

Why is running --safe once, not a good precaution? If we are talking about protecting people from unexpected events, I would say that step has merit, IMHO.

Above said, whatever you decide to do, and what to include or not, it is a net win, benefit, from my perspective. Thanks for listening to my concerns, again. :slight_smile:

all running with --safe does after an upgrade is not run the flow - so all it tells you is that you can still see it in the editor - It won't tell you it's about to go into a spin or crash when you do hit deploy. So you still have to deploy and find out.... so doesn't protect anyone from anything, it's just a recovery mechanism.

Don't get me wrong I think the more backups the better, and doing them at upgrade time is as good a time as any... but when was the last time you did a full backup before Windows update Tuesday ? or your mobile phone upgrade etc...

and don't forget all the docs are open-source too - so please contribute a page.

Correct, --safe is just as you note.

Agreed, but not when you are looking for what to do after upgrading node.

A post was merged into an existing topic: node-RED Backup Flow

Sorry about the bold I do not know how that happened.

I ran the script from within my ~/.node-red folder (not sure if that is correct).
Stop Node-RED \u2714
Remove old version of Node-RED \u2714
Remove old version of Node.js -
Leave existing Node.js - Node v8.15.1 Npm 6.4.1
Clean npm cache -
Install Node-RED core \u2714
Move global nodes to local -
Install extra Pi nodes \u2714
Npm rebuild existing nodes -
Add shortcut commands \u2714
Update systemd script \u2714

But when I 'node-red-start' I see:-
Starting as a systemd service.
9 Jul 12:45:58 - [info]
Welcome to Node-RED

9 Jul 12:45:58 - [info] Node-RED version: v1.1.1
9 Jul 12:45:58 - [info] Node.js version: v12.16.2
9 Jul 12:45:58 - [info] Linux 4.19.97-v7+ arm LE
9 Jul 12:45:59 - [info] Loading palette nodes
9 Jul 12:46:03 - [info] Dashboard version 2.19.3 started at /ui

When I '~/.node-red $ nvm use 8.15.1'
Now using node v8.15.1 (npm v6.4.1)

node-red-start
Starting as a systemd service.
9 Jul 12:57:41 - [info]
Welcome to Node-RED

9 Jul 12:57:41 - [info] Node-RED version: v1.1.1
9 Jul 12:57:41 - [info] Node.js version: v12.16.2
9 Jul 12:57:41 - [info] Linux 4.19.97-v7+ arm LE
9 Jul 12:57:42 - [info] Loading palette nodes

Could anyone shine a light on this ?

Because nvm is not suitable for managing your node.js version when running as a service.

nvm sets up the path to node.js as part of the user environment. When running as a service, your user environment is not used.

Thanks for the quick response. Easy trap to fall into when following the recommended upgrade path on the pi.

Should the node version change when the script said it was leaving 8.15.1 in place ?

Is the correct solution to edit /lib/systemd/system/nodered.service ?

Another observation is that the script sets the RAM to 512/

As I recall, the script does not replace anything if it believes it can leave it alone, because it is believed compatible. This is a bit of issue, if you build a Pi SD card image based on ARM v6 and then load the image on and ARM v7 Pi, the ARM v6 binaries work, just fine on ARM v7, but if you are a purest, you want ARM v7 binaries on ARM v7 based Pi. I solved by only running the script on initial boot of the Pi that has a new OS image. I also remotely deploy my flows, my default images do not stage node-red or node.js binaries.

The 512 is the default for most Pi devices, I have everything from Pi4 8GB to a PiZeroW with 512MB, and last I checked the script was consistent at 512. But, I have heard this is changing, that the script maybe more adaptive to available resources.

I have also read per this forum, that 1/2 physical memory is unofficial standard for the less robust Pi devices. I am testing running at 512 even on the PiZeroW devices I have. But, I don't run the editor on the PiZero devices except on rare exception. I disable the editor by default. But doing so is to avoid hammering the PiZero by miskate than saving resources.

The script said it was left alone but it did not.

It is of course related to how much headroom there is (size of flow). My flows seem to perform best on Pi4 and Pi Zero at 384MB.

The script does not touch the binaries unless needed, I should have been explicit. But you will note that I further said, that the newer script does, as I have been told, adjust some of the settings for different models of Pi devices. The version I have been running always seems to set a default of 512. However, I am building a new image as I type this note, and I expect on my PiZeroW, it will be more adaptive. That is why I noted also, that it is common per others in this forum, to set the limit to half of total memory.

Just a footnote... Ran the latest script, as published, on a PiZeroW device, which only has 512MB RAM total, the node red unit file sets the old memory threshold to 256, not 512 as the previous installation script version did.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.