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

priority plugin: add support for unpacking priorities for queues in TOML config #541

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

cmoussa1
Copy link
Member

Problem

The priority plugin cannot unpack any defined integer priorities for queues in a configuration file, but it was brought up in an offline conversation that it would be nice to be able to set these priorities in a TOML config file.


This PR adds an unpack of an accounting.queue-priorities table in the callback for conf.update in the priority plugin. The table can have any queues and their associated integer priorities. If the queue already exists in the plugin's internal queues map, it will update the associated priority of the queue. If the queue does not exist, it will add the queue to the plugin's internal queues map.

I've added some basic tests that go through defining and changing a priority for a specific queue in a TOML file as well as updated the flux-config-accounting man page to explain how to set up this table.

@cmoussa1 cmoussa1 added new feature new feature plugin related to the multi-factor priority plugin labels Nov 25, 2024
@cmoussa1 cmoussa1 requested a review from grondo November 25, 2024 19:46
Queue new_queue;
new_queue.min_nodes_per_job = 1;
new_queue.max_nodes_per_job = 1;
new_queue.max_time_per_job = 60;
new_queue.priority = priority;
queues[queue_name] = new_queue;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remind me if it is an error if a queue exists in the Flux broker config, but does not exist in the flux-accounting database?

I'm wondering if these defaults make sense if, say, an admin wanted to configure a temporary queue with a high priority. The defaults of max nodes (1) and max time (60m) would not necessarily make sense in this case...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I don't think it is an error - I think the plugin will just return UNKNOWN_QUEUE, meaning it can't find any information about the queue, so it will just apply a priority of 0 for that queue. Perhaps I should just leave out the initialization of max nodes and max time when adding this queue to the map?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I was thinking (just leave out initialization of maximums here). However, we should ask @kkier and @ryanday36 if there is a use case for adding queue priorities for queues not in the accounting db.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. FWIW, those maximums are not currently enforced anywhere in the plugin (yet). But probably good to get @ryanday36 and @kkier's thoughts on it too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can confirm that it is not an error for queues to exist in the broker config but not the accounting database. I've generally only added queues to the accounting database when I have a specific need to do so (i.e. I need to limit access to the queue to specific users). The use case that I can see for queue priorities without the accounting db would be pre-production systems where we're not otherwise worried about banks / fairshare / per-user limits / etc. It might be useful to be able to configure what the accounting plugin is enforcing a bit more (e.g. enforce queue limits, but don't require banks or calculate fairshare). It's pretty easy to set up a dummy-ish bank (guests) and add everyone to it though, which is what we're usually actually doing.

Problem: The priority plugin cannot unpack any defined integer
priorities for queues in a configuration file, but there is at least
one use case to be able to set these priorities in a TOML config file.

Add an unpack of a "accounting.queue-priorities" table in the callback
for conf.update. The table will have any queues and their associated
integer priorities. If the queue already exists in the plugin's
internal queues map, update the associated priority of the queue. If
it does not exist, add the queue to the plugin's internal map.
Problem: The test suite does not contain any tests for configuring
queues in a TOML config file and ensuring a job's priority is affected
by the new configuration.

Add some tests that go through changing the priority for a queue and
ensuring that a job's priority submitted to that queue will change
depending on the configuration.
Problem: The man page for flux-config-accounting is out-of-date and
needs to be updated to include how to define priorities for queues to
be read and used by the priority plugin.

Add a section to the man page explaining how to set integer priorities
for queues in a TOML configuration file.
@cmoussa1
Copy link
Member Author

Just force-pushed this PR to get rid of the initialization of the limits for a queue. So, if a queue is defined in a TOML config file that flux-accounting does not know about, the only thing it is adding is its associated integer priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature new feature plugin related to the multi-factor priority plugin
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants