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

Limits on rabbit resources #203

Open
jameshcorbett opened this issue Aug 27, 2024 · 1 comment
Open

Limits on rabbit resources #203

jameshcorbett opened this issue Aug 27, 2024 · 1 comment

Comments

@jameshcorbett
Copy link
Member

There is currently no way to enforce limits on how many rabbit resources users can request, which is a problem.

PR #202 adds a rudimentary way to enforce a limit on the amount of storage per node for any given job, by adding an exception while the job is in DEPEND state. However, there is no tracking across jobs. Also, ideally jobs would be rejected at submission time, before a jobid is issued, rather than in DEPEND.

@cmoussa1 just a heads up that this might take some flux-accounting work as well? Unclear.

@flux-framework flux-framework deleted a comment Aug 27, 2024
@cmoussa1
Copy link
Member

OK sounds good, let me know what you might require!

Just brainstorming, if your jobtap plugin had access to (at the bare minimum) flux-accounting association data (like all of the associations present on a cluster), you could probably keep track of storage usage per-association within the plugin itself (this is what the priority plugin does to enforce running jobs limits), maybe in a map or something? This way you wouldn't need the priority plugin to be running or anything.

flux-accounting has an export-db command that will fetch basic association data from the DB and port it to a .csv file that might be able to be utilized when populating this internal map within the plugin.

If different associations need to have different limits (i.e some users need to have way more storage allocation than others), then perhaps flux-accounting needs to play more of a role here. But if pretty much every association can have the same limit, then that might save some additional integration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants