I’d remove interface 9. Accounting logs are there for two reasons. First is a trace of states a job/resv went through from its inception to when it leaves the system. The other is for actual accounting (e.g., PBSA). Knowing how many seconds the user was willing to wait doesn’t fall into either one.
Hmm, now that I’m thinking about this more, if we try and compare this to a job, the records that are printed are for actual state changes. The job start. The job was requeued. There isn’t one that says we tried to requeue the job and then one afterwards that said we were successful. Do we want the N and z records? Think about this from the point of view of what someone would want to know after the fact. Do they want to know that an alter request came in and was rejected? I’m not sure. That sounds more like a debug type message. There are server log messages for that. I think people will only want to know what has really happened to their reservations, not things that might have happened. Even if a reservation alter request was accepted, do they care that there is a record that says one was attempted? I think they will only care that the reservation was altered. I don’t think we need to proliferate the size of our accounting log unnecessarily.
I think the only record we need out of the new proposed records is the ‘Z’ record. Speaking of the ‘Z’ record, what happens on a normal reservation reconfirmation (state degraded to confirmed). Should we just reuse that record? We are reconfirming the reservation.