Removed quotas cap

[cheina97]

Description

This PR removes the cap on CPU and memory for tenants.

@QcFe can you confirm if it is secure? If I remember well a normal user cannot customize it's tenant.

[kingmakerbot]

Hi @cheina97. Thanks for your PR.

I am @kingmakerbot. You can interact with me issuing a slash command in the first line of a comment. Currently, I understand the following commands:

• /rebase: Rebase this PR onto the master branch
• /merge: Merge this PR into the master branch
• /hold: Adds hold label to prevent merging with /merge
• /unhold: Removes the hold label to allow merging with /merge
• /deploy-staging: Deploy a staging environment to test this PR (the build-all flag enables user environments building)
• /undeploy-staging: Manually undeploy the staging environment

Make sure this PR appears in the CrownLabs changelog, adding one of the following labels:

• kind/breaking: :boom: Breaking Change
• kind/feature: :rocket: New Feature
• kind/bug: :bug: Bug Fix
• kind/cleanup: :broom: Code Refactoring
• kind/docs: :memo: Documentation

[QcFe]

Thanks, I think it's considerable safe, however, I'd not take the feature away but possibly make it configurable through args & chart... (with a default of 0 meaning no limit)

[frisso]

Wouldn't be possible to set those quota parameters as properties of the tenant itself? With "zero" as "no limit"?

[cheina97]

Wouldn't be possible to set those quota parameters as properties of the tenant itself? With "zero" as "no limit"?

They should be added in the tenant spec. This means a change in the Crownlabs API. I think it should be a good improvement, but it may take some time.

[QcFe]

Would you mind setting the new values inside the helm chart too? Setting as default the old values that were hardcoded...

[cheina97]

/rebase

[cheina97]

Would you mind setting the new values inside the helm chart too? Setting as default the old values that were hardcoded...

Of course 👍

[cheina97]

@QcFe PR is ready or review

[frisso]

If we want to give resources to our students that exceed their capabilities at home, I feel that, per each instance, students should be allowed to create up to 4 cores and 16GB RAM at least (personally, I would say even 8 and 32). Max 10 instances, instead, looks fair to me. @QcFe @cheina97 what do you think?

[cheina97]

If we want to give resources to our students that exceed their capabilities at home, I feel that, per each instance, students should be allowed to create up to 4 cores and 16GB RAM at least (personally, I would say even 8 and 32). Max 10 instances, instead, looks fair to me. @QcFe @cheina97 what do you think?

At the moment the caps are 25 for the CPU, 50GB for RAM and 10 for the instances. What do you think about putting a huge amount of resources as cap? Something like 150 CPU, 300GB of RAM, and 50 instances? Remember that this limit is for all tenants (not only students). The limits of student's resources should be managed with workspaces.

[frisso]

If we want to give resources to our students that exceed their capabilities at home, I feel that, per each instance, students should be allowed to create up to 4 cores and 16GB RAM at least (personally, I would say even 8 and 32). Max 10 instances, instead, looks fair to me. @QcFe @cheina97 what do you think?

At the moment the caps are 25 for the CPU, 50GB for RAM and 10 for the instances. What do you think about putting a huge amount of resources as cap? Something like 150 CPU, 300GB of RAM, and 50 instances? Remember that this limit is for all tenants (not only students). The limits of student's resources should be managed with workspaces.

Current limits (25 CPU, 50GB, 10 instances) look perfect to me.

[frisso]

LGTM, for me we can merge.

[cheina97]

/merge

[cheina97]

/rebase

[cheina97]

/merge