Christopher Moussa

> I'm curious if @cmoussa1 seems a value add here? Not sure what kind of queries currently are done with the `job-archive`. I could definitely see this being useful for...

As pointed out by @garlick in #4430, I can confirm that the following limits described at the top of this issue are currently handled in flux-accounting and was added from...

I'm sorry if this isn't related to this PR but I figured I would double check. Is the plan to also adjust the job-archive DB to match the schema you...

Sounds good! Thanks for clarifying.

IIUC, in terms of the handling of jobs with regard to fairshare, once a resource limit has been reached (`allocated_nodes * time_in_seconds` is the default way to calculate resource usage...

@dongahn yes, those are the two rows I'm referring to! 🙂 I think since the attributes required could be found in @chu11's job-archive, they could be fed into the fairshare...

Just to address your question above in some writing, @dongahn: No matter how many jobs a user submits their priorities are always changing based on their usage. We talked two...

> If we keep the primary (submit) priority as a separate, primary sort key, then things like job hold and expedite could be more easily implemented as a simple adjustment...

> My apology. I got a bit confused. Do the static limits affect job priority calculation other than "if your job exceed a limit, your job will not be rejected...

Yes, sounds like a good plan! My calendar shows a scheduled flux-accounting meeting this Thursday, so if you'd like we can absolutely interlock and start sharing ideas/outlining.