Proposal: Apply Kubernetes Settings

[rak-phillip]

Summary

Reorganize the Kubernetes Settings page so that all changes are applied consistently through making selections and explicitly applying before any changes take effect.

Examples

Apply & Revert changes

Revert and Apply buttons are active when changes have been made, but changes haven't been applied. Clicking on Apply applies the changes, taking the appropriate Restart Kubernetes action based on the selection made. Clicking Revert puts any changes that haven't been applied back to their initial state.

No Changes Made to Form

Apply and Revert buttons are disabled if no changes have been made to the form since the last Apply.

Alert Before Navigation

Alert the user that there are some settings that haven't been applied before navigating away from Kubernetes settings. The user will need to make a choice to Apply or Revert their changes before navigating away; Clicking on cancel will cancel navigation and keep the user on the Kubernetes Settings page.

Motivation

The Kubernetes Settings page has multiple, inconsistent modes of operation that include:

• changing a value (i.e., Kubernetes version) and rendering a dialog to confirm the change before applying on selection
• changing a value (i.e., Port) and rendering an alert at the bottom of the page with a warning that Kubernetes must be reset for changes to take effect
• changing the value for Enable Traefik get applied immediately without any prompt or alert

Batching multiple changes and applying once reduces the time spent waiting for Kubernetes to reset.

Streamlining interactions for Kubernetes Settings will introduce consistency for this page. It also allows us to define patterns for dealing with potentially destructive settings.

Questions

Is it required to reset the cluster for each setting on this page?

Are there any settings that can be applied without such an expensive/destructive action like resetting Kubernetes?

Can these changes be applied more efficiently? (Best case for resetting takes 45 seconds in my tests)

I notice some actions require a Reset (Kubernetes Version, Port, Memory, etc.), while others require a Restart (Container Runtime), is it correct to assume that one action is more destructive than the other?

Drawbacks

• This pattern is inconsistent with other Preferences pages that apply changes immediately upon selection
• This approach doesn't adhere to some UX guidelines for settings pages
  • See Human Interface Guidelines - Preferences Window for example

Alternatives

• Apply all settings upon selection
  • This will require investigation into applying settings without a reset of Kubernetes. Waiting a minimum of 45 seconds to reset is not ideal
• Queue changes to Kubernetes Settings, making use of the Alert pattern that is in use today

[mook-as]

• ❤️ the change to apply & revert. Not sure everybody will agree with me there, but I'm used to KDE / Windows 95, so…
• For the modal dialog on switching — what happens if the user just closes the window? (Presumably, discard changes…) If they just quit the app?
• Wording suggestion for the modal dialog: Apply / Discard Changes / Return to Settings. (I'm not fan of "Don't X" and "Cancel", for clarity reasons.)
• Does this mean all controls are always editable (and, if necessary, we can disable the Apply button when we can't do whatever)?
• For the first question: would it make sense to calculate how "destructive" the change is, and change the wording for Apply? Something like "Apply" → "Apply and Restart" (the latter for restarting the VM, e.g. for CPU changes).

[rak-phillip]

For the modal dialog on switching — what happens if the user just closes the window? (Presumably, discard changes…) If they just quit the app?

I think it would make sense if we raise the alert when closing the window.

If we Quit Rancher Desktop via the tray, we might want to consider this as an implied Discard/Revert.

Wording suggestion for the modal dialog: Apply / Discard Changes / Return to Settings. (I'm not fan of "Don't X" and "Cancel", for clarity reasons.)

Thanks, I think that will be a great improvement

Does this mean all controls are always editable (and, if necessary, we can disable the Apply button when we can't do whatever)?

That should be the case.. we might need to dig into the scenario of what we want to do with the entire form while we're waiting for Kubernetes to start. Perhaps we'll need to introduce some messaging to make it clear why the Apply button might be disabled.

For the first question: would it make sense to calculate how "destructive" the change is, and change the wording for Apply? Something like "Apply" → "Apply and Restart" (the latter for restarting the VM, e.g. for CPU changes).

I like this idea and it should be entirely possible.

[adamkpickering]

I am also a fan of the apply & revert idea.

I think there is a potential problem though. If a user wants to make changes to settings in multiple tabs, they should not have to click apply for each tab - that is not a great workflow. I can think of two ways around this:

1. Don't split settings across multiple tabs. Have all settings that are applied/reverted in one tab, and the apply/revert buttons in that tab (as shown in the above mockups).
2. Continue to split settings across multiple tabs. Have an apply/revert button that applies to changes made in any tab.

I feel that 2 is better. As we add features to RD, we will want (I think) to split settings up into multiple tabs. Though it also applies in the present: it would be awkward to have the setting to enable debug logging in the "Kubernetes Settings" tab, since it has nothing really to do with Kubernetes.

[rak-phillip]

This proposal should only affect Kubernetes setting because each setting on this page potentially requires a costly reset. I'm not sure if it would make sense to apply this pattern to each preferences page, but this is definitely something that we might want to explore.

[rak-phillip]

@scures Can you take a look at this proposal, I'd like to hear your thoughts 🙂