You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to create a resourceQuota in this namespace since there isn't one by default.
We will need a pretty hefty quota since both ope courses are using the namespace. Since we can't limit the notebook resource options to the minimal allocation in rhods without removing them as options from all the users, we need to keep in mind that students technically have the ability to choose any of the allocation options for their notebook.
We have in the docs specified the x-small resource option but we can't enforce this in our current setup. That makes it somewhat tricky to nail down an exact hard quota limit Since in the absolute worst case (incredibly unlikely but technically possible) all students could select other bigger options.
We ran the scale test in ope-rhods-testing with 300 instances and didn't hit our quota so maybe that's a good starting point. As for storage we can pretty comfortably set a limit once we know exactly the number of students we expect (all notebooks create a pvc with one Gi).
Closes: nerc-project/operations#377
Adding this resourceQuota as a component at the cluster scope and adding it to
the rhods-notebooks namespace in the prod cluster. The quota values themselves were
determined based on our resourceQuota in the namespace where we did scale testing,
with a bump to accomodate all the expected students
We need to create a resourceQuota in this namespace since there isn't one by default.
We will need a pretty hefty quota since both ope courses are using the namespace. Since we can't limit the notebook resource options to the minimal allocation in rhods without removing them as options from all the users, we need to keep in mind that students technically have the ability to choose any of the allocation options for their notebook.
We have in the docs specified the x-small resource option but we can't enforce this in our current setup. That makes it somewhat tricky to nail down an exact hard quota limit Since in the absolute worst case (incredibly unlikely but technically possible) all students could select other bigger options.
We ran the scale test in ope-rhods-testing with 300 instances and didn't hit our quota so maybe that's a good starting point. As for storage we can pretty comfortably set a limit once we know exactly the number of students we expect (all notebooks create a pvc with one Gi).
We can use this as a starting point:
We should run the test again with the expected number of students to see how it looks against something like the resourceQuota above.
The text was updated successfully, but these errors were encountered: