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

Introduction of a global resource limit #105

Open
Payback159 opened this issue Jan 18, 2023 · 0 comments
Open

Introduction of a global resource limit #105

Payback159 opened this issue Jan 18, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@Payback159
Copy link
Owner

Is your feature request related to a problem? Please describe.
Tenama already supports limiting the maximum namespace size that can be provisioned via API call. However, cluster resources could be consumed by creating many namespaces.

Since from my point of view the use-cases of Tenama are the access and provisioning of temporary namespaces in a namespace-based shared cluster environment, this behavior could also affect other services on the cluster.

Describe the solution you'd like
Therefore, Tenama should also offer the possibility to configure a global limit over all created namespaces in the future.

I would define the resources the same way on a requests and limits basis and extend namespace creation logic so that tenama checks in advance if the sum of the resource quotas of all namespaces created by tenama that currently exist in the cluster + the new namespace exceed the global quota.

Probably the simplest variant would be to reject the call with a meaningful message and motivate the client to retry at a later time.

Describe alternatives you've considered

Alternatively, we could include a volatile internal queue in Tenama that attempts to create via FIFO the namespaces that would currently exceed the global quota. Of course, this could lead to very long queues if the user sets the lifetime of the namespaces to a "long" time.
Additionally, the client would have to be notified somehow afterwards about the successful creation, otherwise we would end up with long synchronous calls and I don't think that's good.

Additional context
Add any other context or screenshots about the feature request here.

@Payback159 Payback159 added the enhancement New feature or request label Jan 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant