You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had a pretty productive conversation yesterday in a coffee hour talking about a potential need for flux-accounting to maintain consistency with configuration options set in Flux config files, particularly for queues. While the use case for flux-accounting is specific (mostly just to limit access to queues on a per-user basis), it still requires management of which queues are set up on a cluster, and this management potentially comes from two different places (a configuration file for fluxion, and a table in a SQLite database for flux-accounting).
If the way queues are configured currently is okay (will reference @ryanday36's comment in #541 but in case he has any additional comments on this, feel free to leave them here), then perhaps there isn't much to do here for flux-accounting. If not, then maybe flux-accounting should look into adding some support for reading from Flux's config files.
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.
If adding TOML config read support is the case, perhaps the plugin can leverage its conf.update callback to notify the flux-accounting service that configuration has been updated, and the service should get the new configuration with handle.get_conf() and initialize/update the flux-accounting DB with any relevant flux-accounting data.
The text was updated successfully, but these errors were encountered:
cmoussa1
changed the title
config: is there a need for flux-accounting to consistently updated with general flux config?
config: is there a need for flux-accounting to be consistently updated with general flux config?
Dec 3, 2024
We had a pretty productive conversation yesterday in a coffee hour talking about a potential need for flux-accounting to maintain consistency with configuration options set in Flux config files, particularly for queues. While the use case for flux-accounting is specific (mostly just to limit access to queues on a per-user basis), it still requires management of which queues are set up on a cluster, and this management potentially comes from two different places (a configuration file for fluxion, and a table in a SQLite database for flux-accounting).
If the way queues are configured currently is okay (will reference @ryanday36's comment in #541 but in case he has any additional comments on this, feel free to leave them here), then perhaps there isn't much to do here for flux-accounting. If not, then maybe flux-accounting should look into adding some support for reading from Flux's config files.
If adding TOML config read support is the case, perhaps the plugin can leverage its
conf.update
callback to notify the flux-accounting service that configuration has been updated, and the service should get the new configuration withhandle.get_conf()
and initialize/update the flux-accounting DB with any relevant flux-accounting data.The text was updated successfully, but these errors were encountered: