Device Agent to scan for local Node-REDs and auto-import

[joepavitt]

Current Migration Path

• Install FlowFuse Device Agent
• Run Device Agent
• Clashes with my existing NR instance
• Kill NR instance
• Run Device Agent
• Go back to FF UI and Enable Developer Mode
• Open Editor
• Realise I can't import my flows easily
• kill Device Agent
• Run Node-RED locally again
• Copy all flows
• Kill Node-RED
• Run Device-Agent
• Go back to FlowFuse UI
• Open Editor
• Paste in Flows
• Deploy
• Create Snapshot

Ideal Scenario

• Run the Device Agent in a "scan" mode (or something like that?)
• Auto detection of flows, and imports

[hardillb]

Suggestion:

• A command line option for the device-agent that you pass a Node-RED userDir path
• If there isn't an existing project for the device agent it will import the flows.json/flows_cred.json and the credentials secret

This makes is a concious choice to import.

[joepavitt]

That could work well. Although, we'd still have the port clash? But less of an issue if you don't need to have the original Node-RED running I guess?

For the options, the vast majority of cases - it'll be in ~./node-red, no? Why not make migrate an option or scan, something like that. With the extra option of userDir for those that aren't using default options?

[hardillb]

Yep, no need for the old version to be running so no port clash.

Having it default to current users home dir + .node-red would be a valid default with an optional path argument.

[hardillb]

Having thought about this while looking at the device agent for the auto start function, this will need some more padding out.

Is only going to apply to an Application bound device agent, but at the point of starting the device agent it doesn't know how it's bound or if it has an existing snapshot to be deployed.

The device agent doesn't even install Node-RED until it has it's first check in and is told to either use the provided snapshot or an empty one. at which point it will install Node-RED and then either download and run the snapshot or deploy a basically empty flow.

It's at the empty flow stage that it should import a provided existing Node-RED flow.

[Steve-Mcl]

Having thought about this while looking at the device agent for the auto start function, this will need some more padding out.

Is only going to apply to an Application bound device agent, but at the point of starting the device agent it doesn't know how it's bound or if it has an existing snapshot to be deployed.

The device agent doesn't even install Node-RED until it has it's first check in and is told to either use the provided snapshot or an empty one. at which point it will install Node-RED and then either download and run the snapshot or deploy a basically empty flow.

It's at the empty flow stage that it should import a provided existing Node-RED flow.

I concur with all of the above.

In my design prep for this I am facing this chicken scenario Ben mentions.

Difficulties

• userDir may not be ~/.node-red
  • Easy to counter with a prompt "Please enter the full path you your node-red user directory"
• flows might not be in flows.json
  • Easy to counter with a prompt "Please enter the path you your flows"
• Upon OTC setup, there may or may not be existing project dir
  • When project exists, it is likely a user "re-using hardware". My current stance on this is to "clean up"
• A device can be created in as a project device, an application device or an unassigned device. It (currently) doesnt seem sensible to offer this feature to project assigned devices but we have no means (during OTC setup) of knowing where/if the deivce is assigned
  • This can be handled by adding meta data to the response from the OTC registration

Chicken and Egg

Since the OTC is consumed once and deleted, we cannot simply quit and ask the user to "move the device to application and try again" since we dont get device details until after registration - at which point the token is consumed.

Current approach

FF

• Add meta data to the OTC response to include
  • FF version (so agent can determine necessary support exists in the backend)
  • The devices assignment (unassigned, project, application)

Device Agent

• If support is detected (by examining the meta data), perform necessary prompts/logic to locate the following:
  • userDir, flows & flows_creds, package (for modules/version)
  • NOTE: old versions of node-red might be named flows_HOSTNAME.json
  • Will need to handle existing credentialSecret
• Clean up project folder (like we do when device agent detects re-assignement)
• Generate a compatible snapshot and push it as "set-as-target" - all before the first check in
• Ask the user if they want to start the agent (existing feature)
• When the agent starts, it should receive the generated snapshot and modules that were pushed in the prior step

MVP

In this first iteration, to get an MVP, the following is proposed:

• We only ask to import data for devices when they are being registered via OTC
• We only ask to import data for devices that are already application bound
• If the user confirms "Y" to "do you want to import your local flows?", we WILL perform a clean up of the device (that may have been abandoned & left in developer mode, with old flows etc)

[gstout52]

@Steve-Mcl or @joepavitt are we ready to mark this as closed?