Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed quotas cap #875

Merged
merged 1 commit into from
Dec 5, 2023
Merged

Conversation

cheina97
Copy link
Member

@cheina97 cheina97 commented Nov 4, 2023

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.

@cheina97 cheina97 requested a review from a team as a code owner November 4, 2023 11:55
@kingmakerbot
Copy link
Collaborator

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: 💥 Breaking Change
  • kind/feature: 🚀 New Feature
  • kind/bug: 🐛 Bug Fix
  • kind/cleanup: 🧹 Code Refactoring
  • kind/docs: 📝 Documentation

@QcFe
Copy link
Collaborator

QcFe commented Nov 4, 2023

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)

@cheina97 cheina97 marked this pull request as draft November 4, 2023 12:42
@frisso
Copy link
Member

frisso commented Nov 5, 2023

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

@cheina97
Copy link
Member Author

cheina97 commented Nov 5, 2023

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.

@cheina97 cheina97 marked this pull request as ready for review November 6, 2023 18:25
@QcFe
Copy link
Collaborator

QcFe commented Nov 13, 2023

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

@cheina97
Copy link
Member Author

/rebase

@cheina97
Copy link
Member Author

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

Of course 👍

@cheina97 cheina97 force-pushed the frc/qotacap branch 3 times, most recently from 270495a to ae45746 Compare November 30, 2023 20:17
@cheina97
Copy link
Member Author

@QcFe PR is ready or review

@frisso
Copy link
Member

frisso commented Nov 30, 2023

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
Copy link
Member Author

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
Copy link
Member

frisso commented Nov 30, 2023

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.

Copy link
Collaborator

@QcFe QcFe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor stuff

operators/cmd/tenant-operator/main.go Outdated Show resolved Hide resolved
@cheina97 cheina97 force-pushed the frc/qotacap branch 4 times, most recently from d0f264f to 4ba3ea6 Compare December 1, 2023 13:49
@frisso
Copy link
Member

frisso commented Dec 1, 2023

LGTM, for me we can merge.

@cheina97
Copy link
Member Author

cheina97 commented Dec 5, 2023

/merge

@cheina97
Copy link
Member Author

cheina97 commented Dec 5, 2023

/rebase

@cheina97
Copy link
Member Author

cheina97 commented Dec 5, 2023

/merge

@kingmakerbot kingmakerbot merged commit 92340f3 into netgroup-polito:master Dec 5, 2023
32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants