How to restrict the number of workspaces that can be created? Or enable only one workspace running at the same time

[agnesagnes]

Hello,

here is my concern: I would like to create several Che instances on the same host. In order to do that, I will modify each time the ports to use (did it only for 4 users for the moment). But the idea is to be able to control the number of ports and know how many people can be hosted on a single host (and have the maximum number of Che instances). Nevertheless here come the workspaces. Indeed, a user can create as much as workspaces he wants and docker picks the workspace ports in the ephemeral port range.

So here comes my question: can we control by a way or another the number of workspaces running simultaneously?
The ideas that come in my mind would be to:

• Restrict the number of workspaces a user can have (say 10 for example)
• enable only one workspace running at the same time for one Che instance (when one is running, the others are stopped)

Maybe you have a better idea, something already implemented (the must),... I take everything!

[james10174]

@agnesagnes I don't think there is currently an option to limit workspace creation. You could maybe modify the tomcat configuration to prohibit users from accessing the http://ipaddress:8080/dashboard/#/create-workspace and premaking workspaces if you need something right away.

[TylerJewell]

@agnesagnes - this is an interesting idea. Let's explore it further. In Codenvy, we have controls that allow a system administrator to set limits on the total workspaces in three ways:

1. For the total system, limited by RAM - across all users collectively.
2. For a single account, limited by RAM - across all running workspaces. Note that a user can have created many workspaces, but the limit is only applied to those that are running.
3. For a single account, with a hard limit on number of workspaces that can be created.

So with Che - it is a single identity system, so #1 and #2 are identical. So would we support both options?

# Limit the total number of workspaces that the system will start based upon total RAM consumed.
# Allows for unlimited number of workspaces to be created.
che.ram.max

# Limit the total number of workspaces allowed to exist
che.workspace.max

Outside of this, the workspaces are started / stopped from the API level. The dashboard that you see is optional as the IDE is separated from that. So a more aggressive approach is to write your own clients that control when / how a user is allowed to create a workspace.

[agnesagnes]

Finally, the last aggressive approach seems very interesting for me. Because I don't care about having the dashboard and I just want to provide one workspace to each user. Can you tell me more about the possibility to write my own clients? I don't know where to begin in order to achieve that (and to understand the entry points of it).

[agnesagnes]

And I have a subsidiary question: is it possible to create one user by workspace? (for each user to have a different ssh key and git identity to access a different remote repository from bitbucket)

Indeed, I quote your website: "Since Che has a single embedded identity in its default configuration, SSH keys and IDE preferences will be shared across all users accessing workspaces on a single server". So is it possible to have several identities not to share git preferences? (che.properties, rest request,...?)

[TylerJewell]

While che has a single user identity, the underlying workspaces created by che do not have to be the same. So there is certain data that is stored in a Che user profile,such as git keys. But you don't need to. Instead, you can create different stacks in Che that you give to each user. So multiple users are sharing 1 Che instance. However, you have each user use a different stack. That stack creates a workspace from a docker image that has their user-specific configuration already inside the image.

[TylerJewell]

@garagatyi - question - should we add a che.workspace.limit property in the revision of the che properties that sets an upper limit to the number of workspaces that can be generated? Would this be for the number of running workpaces or the number of created workspaces? What happens if a user attempts to exceed this limit - do we present an notification message?

[garagatyi]

I think that @skabashnyuk knows better about that kind of limitation.

[TylerJewell]

@agnesagnes - we discussed this internally, and this sort of limit is not something we are going to consider just yet. These system-wide limits are available in Codenvy's implementation of Eclipse Che.