Smoother installation (good defaults)

[l0rd]

Is your enhancement related to a problem?

We have observed that running Che on a real world, multi-user, scenario requires some changes to the default configuration.

To make it easier for most of the user that install Che (kubernetes cluster admins) we should consider to change the default configurations to reflect the most used ones.

Describe the solution you'd like

• Limit the number of running workspace per user to 1 (CHE_LIMITS_USER_WORKSPACES_RUN_COUNT: "1")
• Idle inactive workspaces after 30 minute of inactivity (CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT: "1800000")
• The default workspaces namespace/project should be <username>-che The default workspaces namespace/project should be <username>-che #14795
• The default PVC strategy common.It's already such:
  • che.properties
  • helm-chart
  • che-operator
• TLS by default - TLS by default #14742
• [POC] TLS by default [POC] TLS by default #15313

These should be the defaults in che.properties and the installers (helm and operator) should not override it.

[skabashnyuk]

@l0rd can you explain the target goal of this change? I worried that "hosted" Che and Che that is running locally may require different configuration parameters because it has different performance requirements.

[ibuziuk]

@skabashnyuk I do not think that it is related to "hosted" Che - those are related to improvements of the default values for any multi-user installation so that the setup would be minimum and desired config would be applied OOTB

[l0rd]

That's not specific to hosted Che. We continuously get feedbacks from real world usage of Che (che.osio is and example but @kameshsampath workshops, @gorkem, and others as well) and I have done a list of default configs that IMHO should be updated. @skabashnyuk that's a proposal, if there is some concern on any of those configurations let's discuss it.

[skabashnyuk]

@l0rd my concerns that some of the values can simply kill or make almost impossible some Che usage scenarios. Like Che server memory request/limit should match osio (512Mi/4Gi) that is too match for local Che. It's hard to use it locally with 16G of RAM with that change it becomes even more harder.

Let's review values one by one.

Limit the number of running workspace per user to 1 (CHE_LIMITS_USER_WORKSPACES_RUN_COUNT: "1")

I think ok for any scenario by default

Enable TLS by default

Are we talking about helm and operator?
In some cases it will make installation a bit harder, is that acceptable compromise?

Idle inactive workspaces after 30 minute of inactivity (CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT: "1800000")

I think ok for any scenario by default

Che server memory request/limit should match osio (512Mi/4Gi)

Value of 4Gi was set in Che6 period, with issues with JsonRPC.
In my latest observation, 1Gi should be enough for the hosted Che load.

Set Che server cpu request/limit as well (500m/1)

Not clear why we need that?

Pool type should be cached (CHE_WORKSPACE_POOL_TYPE: "cached")

Yes and No. No - it doesn't make any sense for local use of Che, Yes - it's an easy fix for hosted, however, it would give some boost
on first X thread, all remaining will be just wasting of resources.
This two tasks #14601 #14600
can give us a better understanding of what we need. Ideally, we should define what the target level of concurrency we want to achieve.

[ibuziuk]

@rhopp could you also prioritize redhat-developer/rh-che#1337 as part of this issue ? JSONRPC setting must also be unified

[l0rd]

@skabashnyuk I will let you and @ibuziuk decide about the memory settings. Your point of view makes perfect sense. I would just like che.osio memory settings to match the default.

For TLS that's the point: we should make it so easy to configure (with automation) that there won't be any reason to disable TLS. That may be a separate issue since it's not just a matter of changing a config.

[l0rd]

@skabashnyuk I have reduced the number of default configs to change in this issue and created a distinct issue for TLS #14742.

[bmicklea]

When we say "local" Che are we thinking of someone running it on their laptop? If so that's not a scenario we ever talk about with prospects and customers - we always suggest running Che on a shared dev cluster. I don't think we should be optimizing defaults for a laptop, although documenting what we'd suggest when running on a laptop would be fine.

Similarly we do often talk to people about the value of being able to run a couple of Workspaces at the same time so seeing the default Workspaces set to 1 might be an issue. I'm less worried about that one though since it's fairly obvious how to change it.

[l0rd]

@bmicklea the goal of this issue is make the default config optimized for the cloud, not for the laptop.

For the number of concurrent workspaces I think we should be conservative. Given the amount of resources needed to start a workspace, when a user try to start a second one without stopping the first it usually fail. I am talking about real world OpenShift cluster where every user has limited resources. And we are still not able to dynamically figure out if a user has enough memory to start a new workspace or not so the failure happens late in the workspace bootstrap process and the error message is an OpenShift event that may be difficult to interpret. To be safe I would recommend limiting the number of running workspaces to 1. And of course that's only the default configuration so it can be changed.

[bmicklea]

Makes sense. From the thread it was unclear if we were talking about a laptop. Thanks for clarifying.

[skabashnyuk]

@l0rd can we mark this issue as resolved or you want to wait for #14795?

[l0rd]

@skabashnyuk let's close it. We are already tracking The default workspaces namespace/project should be <username>-che. as a separated issue.

[slemeur]

I'm reopening this epic as, there are subtasks that are not completed.

[skabashnyuk]

@slemeur @l0rd is this an umbrella issue or there is a DOD for this epic? Also please take a look #14742 (comment). It might require some untrivial operation with certificates. Are you sure we want to make it by default?

[slemeur]

Closing to in favor of following the work on enabling TLS by default: #14742