FlowFuse
Provide pre-configured up to date stacks
Description
When a self-hosted instance is installed, there's no list of pre-defined list of stacks. FlowFuse should provide the last 3 up to date stacks by default to the admin.
I suggest we create migrations each release of Node-RED and each change that requires a stack update.
Requested by:
- https://app-eu1.hubspot.com/contacts/26586079/record/0-3/164219801823
- https://app-eu1.hubspot.com/help-desk/26586079/view/233410279/ticket/118400103668/thread/11196195053#email
Which customers would this be available to
Everyone - CE/Starter/Team/Enterprise
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate
There are changes in tomorrows release to help with this.
The docker/8s installs setup a stack pointing to the latest tag of the stack container. Until tomorrow this pointed at the 3.0.2 NR version (but always the latest FF version).
From next release it will always track the latest NR version as well.
I suspect keeping stacks updated for admins doesn't work out of the box, and mind be incovenient? I'm not sure if we should though it would be nice as an admin to have 1 stack that FlowFuse always keeps updated and maintained every update.
@gstout52 @joepavitt bumping this for planning consideration. Need to work out feasibility and workflow.
Could work on this enable providing pre-configured stacks? https://github.com/FlowFuse/flowfuse/issues/4608#issuecomment-3130728124
My thought is that if we already have something in place that identifies the most recent option, that could be surfaced to new SH customers.
@knolleary assigning this to you as I know you have the room this release, please do size accordingly.
Checking in on this one. I know you're away right now @knolleary , but please provide status on this when you have a moment.
No progress to report for this iteration. Will schedule some time with @hardillb to figure out a plan.
@gstout52 this is a self hosted feature (specific to self hosted instances), just checking I understood the "growth" tag correctly from the engineering meeting earlier, which is to drive FFC connected instances?
@hardillb Thanks for asking -- we want to grow self-hosted as well. I'll review the notes to make sure I've got that documented correctly.
- localfs Gets new nr-launcher as part of the core platform updates, doesn't change Node-RED version without admin installing it and manually updating the stack to the new version (or creating a generic 4.1.x stack directory and updating it's content
- docker Default stack points to the
latesttag, but this is only pulled if it is not present, and will not update if there is a matching container already downloaded. Upgrade instructions include request to manually pull latest container. This will only be applied to new instances and instances suspended/restarted. Does not trigger "new stack" blue button - k8s Default stack points to
latesttag. Driver will always pull if newer version exists in container repo it's pointing at on container creation. Does not trigger new stack upgrade button
Having discussed with @hardillb, the changes made previously so that the default stacks (in docker/k8s) point to latest does ensure customers get the latest stack by default.
The upgrade instructions for Docker already include a step to ensure the container is pulled.
The one gap this leaves is that after an upgrade, whilst the container has been updated for new instances, existing instances will still be running the old container - and as the stack version number hasn't changed, there is no prompt that an update is available.
The scheduled maintenance feature won't currently help as, again, there's no stack version update to trigger the maintenance action.
One option might be to compare the launcher version with the platform version and work on the assumption that if there's a mismatch, there must be an update available - and display the update prompt. The existing update button only works if there is a stack update available - so that would also need updating to trigger a suspend/restart without stack change. My only pause is to think through the possible scenarios where a version mismatch is valid and a suspend/restart won't actually do anything - leaving the customer constantly thinking an update is available.