feat: configure disk storage for Renku 2.0 sessions

[leafty]

Closes #3451.

Add an option to configure disk storage in 3 locations:

• Add launcher
• Modify launcher's resource class
• Custom launch

Breaking change: requires update to renku-data-services.

Add launcher

Modify launcher's resource class

Custom launch

Offcanvas warning
This can happen if the disk storage was set through the API or if the admin changed the quotas on the resource pools.

/deploy renku-data-services=main

[RenkuBot]

You can access the deployment of this PR at https://renku-ci-ui-3463.dev.renku.ch

[andre-code]

The session with the custom disk size work as expected, however I noticed a few things that could be improved:

• The disk size option isn’t visible until you change the resource class selector. It would be better if it was always visible when a resource class is selected. It only happens when the form is use for first time.

• If the disk size exceeds the available limit, the input shows an error, but the error message isn’t displayed. We should make sure the error message is shown when this happens.

• When trying to delete the current value with the keyboard, the toggle gets triggered instead, so it’s not possible to delete the value. This needs to be fixed so users can delete the value without triggering the toggle.
  

Also, I’m curious—why add the toggle to show the input instead of just keeping the input always visible? It could make the experience smoother for the user.

[leafty]

Also, I’m curious—why add the toggle to show the input instead of just keeping the input always visible? It could make the experience smoother for the user.

The question is: how to handle the difference between keeping the value unset (and thus using the default value from the resource class) and setting the value equal to the default for the resource class?

[lorenzo-cavazzi]

After thinking about this, I wonder if we need to distinguish between default and manually set.
Once the session is started, it doesn't matter if the value was manually set or taken from the default. I agree with Andrea that leaving the slider always visible simplifies the UX.

[leafty]

After thinking about this, I wonder if we need to distinguish between default and manually set.

Yes, because the default value can be changed by an admin, while a value specifically set here will only be changed by the project members.

[lorenzo-cavazzi]

Yes, because the default value can be changed by an admin, while a value specifically set here will only be changed by the project members.

True, but would that make any difference to users with running sessions? Even if an admin changes the default, the running sessions won't be affected immediately. And we don't want to accidentally resize the disk while patching as well.
It seems safer (and easier) to use the default for the first input and not automatically modify that as long as the session lives

[leafty]

True, but would that make any difference to users with running sessions? Even if an admin changes the default, the running sessions won't be affected immediately. And we don't want to accidentally resize the disk while patching as well.
It seems safer (and easier) to use the default for the first input and not automatically modify that as long as the session lives

This basically does not apply, disk storage can only affect new sessions. The disk is not resized upon pause/resume (that would be very disruptive).

I think it would be good to merge a way to configure disk storage instead of insisting upon a better way to configure storage (you're free to patch it afterwards).

[leafty]

Also, storing the value when not touched by users would prevent admins from "upgrading" the session classes. Right now, if an admin upgrades the default storage to be 4GB instead of 1GB, then all users without a value set would benefit from the upgrade. With your solution, no user would get the automatic upgrade to session storage.

[lorenzo-cavazzi]

I totally agree with this:

I think it would be good to merge a way to configure disk storage instead of insisting upon a better way to configure storage (you're free to patch it afterwards).

I might have lost some bits here and there; I thought my suggestions implied less work, not more. And I'm afraid of the possible negative consequences of downsizing. Anyway, let's try to merge the changes and, if needed, we can adjust details later

[leafty]

And I'm afraid of the possible negative consequences of downsizing.

Why? This cannot affect any existing session.

[leafty]

@lorenzo-cavazzi feel free to patch things here or make an alternate PR from here.

[andre-code]

The code looks great and works as expected. It's intuitive, and the error messages are clear and helpful. Great job!

[RenkuBot]

Tearing down the temporary RenkuLab deplyoment for this PR.