Update individual flows on an active NR instance?

Core Development
1

Most elegant way to deploy an individual flow to active NR instance, from within a flow or otherwise? I have been playing with this idea for a while, and tried various methods.

The method I find the most logical is to analyze the flows file, get the list of flows, and build a new flows file that matches the list of individual flows replacing those that have newer variants.

This idea has three(3) issues that I see:

  1. This is off the reservation, if NR development changes the internal flows data structure or format, the solution will (likely) break.

  2. Configuration nodes do not consistently support credentials management in a uniform manner, just changing the secret in settings, does not cover all scenarios. Even when you do drop a new/updated flows file into place, it is not just restart NR and good to go situation right now. The mysql configuration node id/password orphaning is just one example.

  3. UI elements of the dashboard are a problem in general when you import updated flows, orphaned objects, duplicated objects, etc. How to find and resolve issues is not, from an API perspective straight-forward. For example UI object presentation placement changes inconsistently is one such example, the so called 'spacers' issue.

I actually wrote a flow that audits flows, and reports to a database that a given device has pending individual flow updates, pending NR update, Node update, NPM update, etc. This works. but this only half of the goal. I have also experimented with Ansible, SaltStack other related solutions, but all of this still only address part of the issue.

To those that ask why even consider this... Because I need this feature to exist in some form. I have several ideas that could leverage NR at a very large scale across 100s if not 1000s of devices or more, but for the above issues which disqualify NR. NR has so much potential, but for a few quirks in this regard.

To those that would suggest just create a canned image, and update that image in total. Yes, this works, but this is unacceptable to many/most controlled environments, where the total number of changes is to be limited, validated, etc. An entire new image, in a responsible DEV, UAT, PROD progression is a considerable resource commitment when the change is just a single flow being updated. Running NR in a docker instance does take some of the pain out of this situation of course.

Never mind that changing the SD card is quite intrusive. Although, using PXE has the potential to take some of the pain out of SD card swapping, but PXE option is not available except for Pi 4 devices for example. Moreover, stateless deployment has its own set of issues, which I will not address here.

None of this is a knock on NR. NR is a wonderful solution. The admin API or more explicitly the deployment API needs some TLC to get to a painless update of individual flows.

1 Like
2

The admin api does allow for updating individual flows (in the sense we call a whole tab a flow) - PUT /flow/:id : Node-RED

It is hard to make it any more finer grained as a group of connected nodes has no overall identifier that can be used over the api.

Configuration nodes do not consistently support credentials management in a uniform manner,

Any node that is not storing credentials using the credentials mechanisms we have should have an issue raised against it.

The mysql configuration node id/password orphaning is just one example.

An example of what exactly?

UI elements of the dashboard

Yes, the dashboard doesn't lend itself to have bits and pieces of it imported into other instances without some manual tidy up. No doubt if some specific scenarios were identified that didn't work as expected it might be possible to improve matters. But it needs contributors who are interested in improving it to actually do so.

3

Yes, the individual flows can be deployed but if any configuration nodes are shared, you end up with multiple configuration nodes. An example of this is defining a broker configuration node. Even if the name of the broken node is the same name, you end up with 2 or more instances of the same named broker configuration node. The same name does not seem to be seen as a possible consolidation opportunity. The logic of this is clear, each flow is unique unto its-self, it is the safest path. But this is a case of where the UI allows consolidation of the given broker nodes to one shared instance, but I have yet to see how the API flow import can do this as yet. Even the UI does try to avoid this on input in later versions of NR of course. So I expect over time this shared configuration node logic will mature into an API method if or when possible.

The mysql connection configuration node, every time I load a flow via the API or the UI, I have to explicitly access the configuration node and explicitly set the id and password. I raised this as an issue when I was new to NR, and I was told at the time, this is by design, that the embedded id/password is removed on import or export. This is inspite of use of a valid and common secret across NR instances. This is horrible from a deployment perspective. Especially if you have multiple flows that have mysql configuration nodes, you have the node consolidation issue, as noted above, as well id/password issue to compound the issue.

Yeah the dashboard, needs some TLC, if not some rework. The overlapping UI group tabs drives me nuts at times. :slight_smile: I keep reminding myself the 'default' dashboard is not the only option available.

But again, all of this is specific to deployment specific use case I noted. Which is a bit unique in its own right. Figure once in a while I will raise these issues, so when opportunity presents they may be addressed as applicable.

4

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