Initial UI support for HA mode

[knolleary]

Description

Second attempt as UI elements for introducing HA mode.

Enabling HA mode

HA mode can be enabled/disabled on an instance. This is done via a new Settings/HA page:

(Link to docs is currently empty as the docs need writing)

Clicking enable shows confirmation dialog:

When enabled, an HA badge is shown in the header. The badge, when clicked on, takes the user to the HA Settings page for the instance.

This same badge is used consistently through-out:

Team Applications

Application Instances

[knolleary]

Investigating the UI test failures.

[knolleary]

UX tests now passing.

[joepavitt]

As an MVP, this UX is okay, my (longer term) gripe is with the fact that you enable HA on the Production instance. I feel like HA is something that's enabled on the instance I still want to develop with, and FlowForge should just be handling the scalability in the background (e.g. by setting up additional instances for me)

Wanted to document the following thinking:

Ideal Path UX

1. I would expect to be able to enable HA mode on an Instance ✅
2. I would expect this instance to still retain it's Editor access
3. I would expect another (or multiple) instance(s) to be spun up in the background
4. I shouldn't then have to do anything manual, other than continue to edit this Instance, and the other HA Instances should automatically update

Iteration 1 UX

1. Steps 1-3 from Ideal Path
2. Pipeline is automatically setup that allows me to manually push from my Development Instance to my HA instances.

Iteration 2 UX

This is essentially the ideal path, but utilises Pipelines in order to map the Development > HA Instances

1. Steps 1-3 from Ideal Path
2. Pipeline is automatically setup that auto-triggers when a deploy is conducted on Development

[joepavitt]

Just to check my understanding here too @knolleary, is this diagram accurate?

Where steps are:

1. Create an Instance (Instance 1)
2. Enable HA on that Instance
3. Create another (development) Instance (Instance 2)
4. Setup a pipeline to map Instance 2 to Instance 1
5. Manually deploy to Instance 1 via the Pipeline whenever we want to push to "Production" environment

[joepavitt]

Thinking about this further, I'm guessing the advantage of what we have now is that the user will still need to configure environment variables, etc. for their production instance? In my proposal, that's less intuitive as that instance(s) are setup in the background.

[knolleary]

Just to check my understanding here too @knolleary, is this diagram accurate?

Yes that is accurate for this iteration of the feature.

I feel like HA is something that's enabled on the instance I still want to develop with, and FlowForge should just be handling the scalability in the background (e.g. by setting up additional instances for me)

There are a number of choices the user has to make when setting up their production instance that means we can't do it all automatically for them and can't be hidden away.

• The production instance needs its own url (ie name).
• They may want a different instance type - ie develop on a Small, production is a large.
• Env vars need setting up etc.

[joepavitt]

Yeah, realised this after I posted my initial comment. I'll have a little more of a think about the existing UX to see if any further small wins

[joepavitt]

Have just pushed e5f39b7 it adds a tooltip to the "Open Editor" button that explains why the button is disabled. This was the most obvious gotcha that, I understood, but it wasn't explicit.

The bump to a new ui-components, etc. can be done separately, as it is functional, doesn't doesn't update the tooltip with the polling updates.

[joepavitt]

awaiting tests to run before merging - but should be fine