Open cmoussa1 opened 4 months ago
Attention: Patch coverage is 64.70588%
with 6 lines
in your changes missing coverage. Please review.
Project coverage is 83.08%. Comparing base (
a6bd897
) to head (5747337
). Report is 6 commits behind head on master.
Thank you both for the first pass! I've force-pushed up some changes to drop FLUX_KVS_WATCH
, use libflux-idset, and change how the test is structured to instead use flux resource R --include=0 | flux R decode --count=core
(this check makes a lot more sense than what I had).
I've also added some comments in code where suggested.
Problem
The priority plugin does not know about basic system information it will need in order to enforce a max-cores limit per association, such as the number of cores on a node.
This PR adds an estimation of a cores-per-node count estimate during the initialization of the priority plugin by fetching
resource.R
from the KVS. It stores this estimate in a global variable in the plugin. The plan is to use this count when calculating the number of cores used by a job when onlynnodes
are specified. I think that this count might not be exactly right for systems where the core count per-node might be different throughout the system, but I figure this could at least be a good estimate and a start for tracking and enforcing resource limit per-association across all of their running jobs (see conversation in flux-framework/flux-core#6091).This count is also added to the list of information returned in the callback for
plugin.query
.