OpenFlow and NodeRed Local: Errors when creating from OpenIAP Agent

[renierduvenhage]

Good day

I have my own OpenFlow instance (newly created) running v1.5.9

I followed the instructions on the following video to get a setup for NodeRed on a local machine (in the end to deploy this on remote machines): https://www.youtube.com/watch?v=YdH3h3iAu-Y

I can successfully create a noderedagent running on a local machine when running it in VSCode (with the following documentation: GitHub - openiap/noderedagent)

But as soon as I publish this package to OpenFlow and then try to create a noderedagent from the OpenIAP Agent, the following errors appear:

I don’t have grpc lines in my docker-compose.yaml file. As soon as I add the following lines in my docker compose file the OpenFlow instance returns “404 Page Not Found” for the OpenFlow instance:

The noderedagent is working when running in VSCode. But it won’t work when I run it via the published package (which I assume is because I don’t grpc, but adding this breaks my OpenFlow instance).

When the noderedagent is created via the OpenIAP Agent, it adds the following environment variables automatically from the package that I published:

The above variables is exactly the same as the ones when running the noderedagent via VSCode.

What am I missing or doing wrong for this not to work?

[Allan_Zimmermann]

line 83 is inside the get function.This is used in 2 places. It is used to load the openid connect information if oidc_config environment variable has been set, and to load the user profile doing openid connect login ( url either received from oidc metadata url or using oidc_userinfo_endpoint environment variable. )

The wss in the error sounds like an api url has been places in the wrong place ( or oidc_config has not been properly parsed to the package. I think i still have some buggy code that is trying to “guess” the oidc_config if it is missing, so this should always be set )

Just to be clear, are you trying to run this nodered inside docker ?

• if so, can I ask why not use the image I supply ? But is perfectly fine to need to run a custom version, but is important, that if are trying to run in inside docker, most of these must be set by openiap, so you need remove domain, oidc_config, port and externalport.
• If not, and you are trying to run this on a remote machine, either on a node agent or an assistant. Then yes, this indeed looks very strange, from the screenshots all appears to be correct. how old is the agent/assistant ? ie. what version is it running ? if running on a nodeagent you can update easily by simply running the npx command again but skipping the setup with ctrl+c

[renierduvenhage]

Hi @Allan_Zimmermann

I am trying to do the same as my current setup on OpenFlow v1.4.x where you could install NodeRed on a remote machine to retrieve data and then that talks to an OpenFlow instance on my cloud setup (setting up NodeRed using npm packages as was did in v1.4 and earlier).

My current setup has on v1.4.x has a few issues, I am therefore migrating to a new instance in stead of upgrading the old instance.

This therefore talks to your second point mentioned above (hence why I am not using the image supplied - all of my images that runs on the cloud setup uses the default image and those are working as expected).

I am trying to run this from the OpenIAP Ageing and that is where I am getting the errors.

In terms of versions:

1. Nodejs on the remote machine: v16.17.1
2. The noderedagent package that I published as per the package.json file:
   • @openiap/noderedagent: v1.5.9
   • @openiap/nodeapi: v0.0.38
   • OpenIAP Agent (windows): v0.0.22
3. noderedagent (as per noderedagen.json file in the package): v0.0.1

Not sure if the above is the correct version numbers you are looking for. I downloaded the OpenIAP windows agent yesterday and the noderedagent package was cloned from github this morning.

[renierduvenhage]

I see in my launch.json file before I published the noderedagent to OpenFlow, the apiurl is set as:

Perhaps the error is coming from this?

But this url was created automatically in vscode when I did the setup (if I’m not mistaken). If this is the issue, what should the url be if my setup does not contain grpc in docker-compose.yaml? Or should grps be added?

[Allan_Zimmermann]

I need to hire someone to help me find better names for things, sorry it sometimes gets confusing.

openiap (openflow) first had a protocol based on json, designed to be used inside websockets. This has been almost the same ( only adding, never removing or changing anything ) from way before i made it open source.
In version 1.5 i made a new protocol using protobuf. I then added multiple “carrier” protocols of this into openflow ( namepipes, TCP, REST/HTTP, WebSockets and GRPC ( googles implementation of protobuff over http/v2 ) )
This have had a few breaking changes in the first releases but have been stable since 1.5.4

The old “remote nodereds” are talking to version 1 of my protocol, this can talk to any version of openflow.
The “nodeagent” that you can install a service, but is also used in my “agent images” used inside docker/kubernetes and inside the assistent. Only talks version 2 of the protocol.
The idea is, we feed in a api url to the agent ( and this can be any of the carries protocols ) and it then feeds more details information to the packages it runs.

So the nodered agent package can also talk any of those protocols, so using wss is not an issue for the api url.
So right now, i would say the problem is oidc_config is wrong or missing.

Since you have access to the source of your own nodered package, could you do a console.log(url) inside the async function get function so we can see what value it’s getting, maybe that wil give a hint on where it’s getting the value from.
Also, it would be helpfull if you could add a console.log(process.env.oidc_config) below the console.log("port: " + port + " externalport: " + process.env.externalport) line, so we can see if it’s getting the correct value.

You can run the agent package in a console ( instead of a service ) by calling the npx package with the -service switch. If you do that, you can enable printing the package output to the console ( so you don’t have to look inside openflow’s web interface for the output ) bu running it with DEBUG=true, so

DEBUG=true npx -y @openiap/nodeagent -service

Also might be worth updating to latest version ( 0.0.104 )
by running

npm cache clean --force
npx clear-npx-cache
# and the run this to install latest version and run as service in console with
DEBUG=true npx -y @openiap/nodeagent -service