-
Notifications
You must be signed in to change notification settings - Fork 10
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
plugin: add configurable priority factors via TOML conf.update
#295
Conversation
770620a
to
e49df81
Compare
conf.update
conf.update
e49df81
to
8c19d56
Compare
8c19d56
to
48dcdf6
Compare
conf.update
conf.update
48dcdf6
to
1f9ac99
Compare
1f9ac99
to
2485a88
Compare
conf.update
conf.update
I've continued to make progress on adding the "age" factor to the priority plugin, and I think it would be helpful to have this PR reviewed first as the "age" factor stuff is built on top of these commits. :-) @grondo, if you have a chance later this week or next, could you give this a review please? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty good! I just had a suggestion on the layout of the configuration to more closely match how other Flux subsystems are organized. Let me know what you think. Definitely open for discussion!
A flux-config-accounting(5)
man page should probably be added as well documenting the new configuration parameters and expanded when new configuration values are added.
src/plugins/mf_priority.cpp
Outdated
"{s?{s?{s?i, s?i}}}", | ||
"conf", "priority_factors", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: put all flux-accounting values under one heading, maybe [accounting]
?
Will all configurable priority factors actually be weights? If so, then maybe the sub-table should
just be factor-weights
and the individual factor weights like fairshare
, queue
, age
, etc.
So in the config file it would be
[accounting.factor-weights]
fairshare = 1
age = 1
and so on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good suggestion, thanks! I've just pushed up my branch that makes this change to use a sub-table [accounting.factor-weights]
.
Problem: The priority plugin uses hard-coded values for the weights associated with each factor used to calculate a job's priority. Add a new callback to the plugin that extracts information pertaining to the priorities' respective weights used in the multi-factor priority calculation. Place the weight information in a map where the key is a string of the factor's name and the value is the factor's associated integer weight.
Problem: The priority_calculation () function uses hard-coded values for its calculation of a job's priority, but the plugin can read from a configurable TOML file now via the conf.update callback. Use the values located in the priority_weights map. If no values are found in a conf.update, the values for the factors located in the priority_weights map will be -1, so in this case, just use default values.
Problem: There exist no tests for updating the plugin via conf-update. Add some tests.
2485a88
to
22cf1a5
Compare
Thanks for the review @grondo!
Sure thing, I'd be happy to document this. Should I add that manpage to the |
Yeah, are there no manpages yet for flux-accounting? We should start with this one. It should probably go in |
Not yet, but I'll go ahead and take a crack at adding one for the config parameters proposed in this PR. 👍 |
I just pushed up a commit to add a new manpage to the |
Great! Unfortunately I think some infrastructure is still needed to build and install the man page. I think you could check out flux-sched for the requirements, but I can try to help later |
Thanks @grondo! I've started trying to copy over the infrastructure from flux-core and flux-sched to enable building and installing the man pages (I've pushed up another commit that you'll probably notice is failing 😉 ). I'm going to try and keep hacking away at this to see if I can get it to build successfully |
cfabd1a
to
5a496dd
Compare
708370d
to
e4ef5df
Compare
OK, after a lot of tinkering I think I was finally able to get the man pages infrastructure set up. 😆 The last two commits should have all of the required files added and modified to be able to build and install the documentation for the priority plugin configuration, which can be viewed with |
doc/man5/flux-config-accounting.rst
Outdated
The flux-accounting priority plugin can be configured to assign different | ||
weights to the different factors used when calculating a job's priority. | ||
Assigning a higher weight to a factor will result in it having more | ||
influence in the calculated priority for a job. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this should mention the default weight for factors that are not set in the config file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion, thanks. I've just force-pushed up a fix that adds a table which lists the default weights for factors if they are not configured.
Problem: There is no documentation for configuring the different factors used in calculating a job's priority. Add a new manpage to the doc/ folder that outlines the configuration process for the various factors used in the priority plugin.
Problem: The am_check_pymod.m4 file in flux-accounting is out-of-date compared to flux-core's, which results in a failure to run ./configure with --enable-docs set and the introduction of man pages to flux-accounting. Update am_check_pymod.m4 to match flux-core's.
Problem: flux-accounting has no way to build and install its man pages. Copy over the docs infrastructure from flux-sched and flux-core to be able to build the manpages for flux-accounting.
e4ef5df
to
da285a9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! LGTM!
Thanks! I'll set MWP here then |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #295 +/- ##
==========================================
+ Coverage 83.30% 83.34% +0.04%
==========================================
Files 23 23
Lines 1545 1555 +10
==========================================
+ Hits 1287 1296 +9
- Misses 258 259 +1
|
Background
While working on #291, I found it hard to add a new factor to the priority plugin without having to change all of the sharness tests that checked for a specific priority number. A great suggestion was made that perhaps the plugin could make use of the
conf.update
callback topic, which would allow for configuration of values in a TOML file that can be extracted in the plugin and stored for future use. This would be especially useful for the integer weights of the various factors used in the priority calculation of a job for a couple of reasons:This PR adds TOML configuration support for the priority factors to the multi-factor priority plugin. The
conf_update_cb ()
callback that is added to the plugin looks for a[priority_factors]
section in the config file where the various priority factors are defined along with their associated integer weights. It extracts these values and places them in a map, where the key is the name of the factor and the value is its integer weight. These weights are then used in thepriority_calculation ()
helper function where job priority is calculated. Previously, this helper function was using hard-coded values for the weights of each factor.Finally, a new sharness test is added where checks are made that the priority of a job can be adjusted depending on the
[priority_factors]
configuration in the TOML file, as well as ensuring that no configuration of the priority factors (as well as using the defaulturgency
) results in a job just using default weights set in the plugin.