One of the first (and potentially simplest) actionable items to begin supporting something like a centralized accounting database is to increase the granularity of each row in association_table. If a user has access to and can run jobs from more than one cluster, than it is important to be able to distinguish which jobs/usage/fair-share/other properties are specific to which cluster.
Thus, updating the primary key in association_table to include the username, bank, and the name of the cluster seems like a reasonable first step. While this could be manually set by the admin when adding a new row to association_table (or editing an existing one), the cluster property seems like it ought to be directly queried and automatically applied to the data being inserted into the table. So I'll probably need to find or write a small utility function to grab the cluster name when updating existing rows or adding new ones.
One of the first (and potentially simplest) actionable items to begin supporting something like a centralized accounting database is to increase the granularity of each row in
association_table. If a user has access to and can run jobs from more than one cluster, than it is important to be able to distinguish which jobs/usage/fair-share/other properties are specific to which cluster.Thus, updating the primary key in
association_tableto include the username, bank, and the name of the cluster seems like a reasonable first step. While this could be manually set by the admin when adding a new row toassociation_table(or editing an existing one), the cluster property seems like it ought to be directly queried and automatically applied to the data being inserted into the table. So I'll probably need to find or write a small utility function to grab the cluster name when updating existing rows or adding new ones.