Implement workspace cap that prevents users from creating more than X workspaces

[bmicklea]

Problem:
By default users are not limited in the number of workspaces they can create (only in the number that they can have running simultaneously). However, if snapshotting is turned on a user who creates a large number of workspaces can end up using a lot of storage for all their snapshots.

Possible solution:
Implement a configuration parameter that limits the total number of workspaces a user can have (running and stopped).

[TylerJewell]

@slemeur - similar to the RAM cap - we'll need a friendly error message when a user tries to create a workspace when they do not have any more workspaces left to create.

[sleshchenko]

Seems that it already is implemented and can be configured by limits.user.workspaces.count property:

1. Property in configuration
2. Configured value for aio.codenvy-dev.com = 30
3. Logic that denies users to create more than X workspaces
   @bmicklea Can we close this issue or should we rework something in current implementation?

[bmicklea]

@sleshchenko I thought that property controlled the number of running workspaces. So I thought that if I set that property to 10 then I could create 100 workspaces, but only run 10 at the same time.

This issue was to create a separate property to control the total number of workspaces (running or stopped) the user could create. So that if this new property was set to 10 then I would only be able to create 10 workspaces in total.

Can you confirm?

[sleshchenko]

Yes.

[TylerJewell]

@bmicklea @sleshchenko @JamesDrummond - seems that we need a couple things:
1: We should have two sets of properties. One set of limits that apply to workspaces running. Another set of properties that apply to the total number of owrkspaces (running & stopped). We should give admins control over both sets of configuration.
2: This will be a common configuration thing for admins. @JamesDrummond - have you tested this with your codenvy onprem and do we have a section on this in scalability, or sizing? This is a critical utility for helping admins control production. It seems that admins will want to set caps for workspaces, workspaces running, or the RAM in an account.

[bmicklea]

@sleshchenko @vkuznyetsov is any more information needed to move this issue from status/analyzing to status/open-for-dev?

[sleshchenko]

@bmicklea I think we can close this issue because it is implemented in master by limits.user.workspaces.count property. And we can create new issue/issues for properties described by Tyler

[bmicklea]

Added a new issue: #792