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
{{ message }}
This repository has been archived by the owner on Apr 25, 2024. It is now read-only.
The current state of AccountQuota allows specifying exactly one account the account quota applies to. All resources within namespaces the account owns count towards the quota. Hence, a common setup is to have an account for each User, which in return also has an AccountQuota.
One observation in this setup is, that a lot of the accountquotas across accounts do not really differ and are required to be in sync with some form of meta quota that should be applied to certain groups of accounts (e.g. developers, admins etc.). Accomplishing this goal is not trivial with the current set of features in kiosk, since this requires some sort of manual work or scripting to keep those accountquotas in sync.
Solution
A solution to this problem could be the AccountQuotaSet. This resource ensures that for a certain set of accounts an accountquota exists with the specified hard limits. Changes to the AccountQuotaSet would be applied to the children accountquotas. If a new account satisfies the account label selector an accountquota for this account is created. Conversely, if the labels of an account change (or the account is deleted) the corresponding accountquota would be deleted.
Potential Implementation
The implementation of the AccountQuotaSet would require 3 parts:
CRD: we would need a new crd that defines the AccountQuotaSet (mostly a AccountQuota template and account label selector)
Controller: obviously we also need a new controller that handles the creation / updating / deletion of corresponding accountquotas. One open question I have, how we can efficiently cache the accounts by their label selectors? Is it enough to just search everytime the informer cache via label selector?
Admission: should be straight forward and checks for basically the same things the AccountQuota admission controller checks.
The text was updated successfully, but these errors were encountered:
Problem
The current state of AccountQuota allows specifying exactly one account the account quota applies to. All resources within namespaces the account owns count towards the quota. Hence, a common setup is to have an account for each User, which in return also has an AccountQuota.
One observation in this setup is, that a lot of the accountquotas across accounts do not really differ and are required to be in sync with some form of meta quota that should be applied to certain groups of accounts (e.g. developers, admins etc.). Accomplishing this goal is not trivial with the current set of features in kiosk, since this requires some sort of manual work or scripting to keep those accountquotas in sync.
Solution
A solution to this problem could be the AccountQuotaSet. This resource ensures that for a certain set of accounts an accountquota exists with the specified hard limits. Changes to the AccountQuotaSet would be applied to the children accountquotas. If a new account satisfies the account label selector an accountquota for this account is created. Conversely, if the labels of an account change (or the account is deleted) the corresponding accountquota would be deleted.
Potential Implementation
The implementation of the AccountQuotaSet would require 3 parts:
The text was updated successfully, but these errors were encountered: