search

FlowFuse / flowfuse

Build bespoke, flexible, and resilient manufacturing low-code applications with FlowFuse and Node-RED
https://flowfuse.com
Other
263 stars 63 forks source link

"Restart FlowFuse" Button for Administrators in FlowFuse UI #3211

Open elenaviter opened 9 months ago

elenaviter commented 9 months ago

Description

The FlowFuse user interface is designed to abstract away complex underlying processes. In organizations with structured roles, individuals responsible for deploying components (developers in development environments, ops in CI/CD, and business delivery in production) are granted varying levels of access.

Currently, applying a license in FlowFuse is considered a 'soft admin' action and can be done through the UI. However, a specific scenario arises when applying a license to a previously non-licensed FlowFuse instance. This action necessitates a restart of the FlowFuse container.

To streamline this process and maintain role-based access integrity, it is proposed to introduce a 'Restart FlowFuse' button within the UI. This feature will enable soft admins to complete the license application process without the need for direct Kubernetes access, adhering to the principle of minimizing direct intervention with the system's 'wheels'.

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

hardillb commented 9 months ago

This suffers from the same problem that Node-RED has that it can't restart it's self (to update or remove loaded nodes). The container based deployments can use the container runtime to restart the container if the application exits, but the localfs builds can't restart themselves if they exit.

I suggest it would be better to allow the feature flags and any code that needs to be re-initialise when a license is added to remove the need for the restart.

elenaviter commented 8 months ago

This suffers from the same problem that Node-RED has that it can't restart it's self (to update or remove loaded nodes). The container based deployments can use the container runtime to restart the container if the application exits, but the localfs builds can't restart themselves if they exit.

I suggest it would be better to allow the feature flags and any code that needs to be re-initialise when a license is added to remove the need for the restart.

Hi, @hardillb, Thank you for your response. I appreciate the insights.

This issue is becoming increasingly important as we transition our licenses into production environments. In the case of Node-RED projects, whose lifecycle we manage via the FF API (for example, by initiating restarts), addressing this isn't a concern, as we can centrally manage project restarts during scheduled maintenance windows. However, my question pertains to any additional steps that might be necessary at the FlowFuse core level following the application of a license to ensure the changes take effect. I've noticed that the team library isn't accessible post-license application (this also applies to custom artifactories, which we don't use, but it's still a notable feature that seems to require a restart to become operational). Could we estimate how complex could it be to frame the licensed features with conditions so that they reveal once the license applies w/o need for restart?

knolleary commented 8 months ago

One of the main blockers to enabling EE features without a restart is that fastify doesn't allow additional routes to be registered after it has been started. See https://github.com/fastify/fastify/issues/1771 for example.

One possible solution would be for us to always load all the EE code regardless of license state, and ensure all of the routes contain a license check and return an appropriate response code. However that goes against our principle of trying to keeping the OS and EE code separated.

knolleary commented 8 months ago

This suffers from the same problem that Node-RED has that it can't restart it's self

This is slightly different in that we aren't needing to unload modules from memory (like in the case of NR restart). Our unit tests start/stop the forge app all the time without needing a full process restart.

So I think it would be technically possible to have the ability to pull down and reinitialise the forge server without exiting the process.