They do, but they have to do it after this occurrence has finished. You only have the ability to alter the next occurrence. This means they’ll need to wait until the current occurrence finishes, extend the next one, wait until that occurrence finishes, extend the next one, etc. This is not a user friendly interface.
You bring up a good point of who is going to use this command. If the admin extends the reservation, the user could be clueless that this happened. They could be confused. If they do the alter themselves, then they’ll need to be a savvy user to understand exactly what it means to alter a standing reservation. Of course you probably need to be a savvy user to use pbs_ralter in the first place.
You are not covering my use case. I think it is a real use case too. However intuitive it is that you get a long and a short occurrence, the user might only submit jobs that are near the length of the reservation. One of the main use cases of this RFE is to allow the user to extend a reservation when they know their jobs aren’t going to finish in time. This could force them to extend the next, and the next, etc.
There is one other way we could solve this use case. It would be a change to how standing reservations work. We could just not start jobs that wouldn’t end before the end of the occurrence. The functionality of running all jobs in a reservation regardless of if they would finish in time was meant for advance reservations. Since the whole reservation is going away after its time is up, there is no reason to not start all the jobs that we can. There is always a possibility it might finish early. This changes with standing reservations. Should we start a job that we know can’t finish in time but could in a future occurrence?
You are correct that not all occurrences of a standing reservation will be on the same nodes. This doesn’t cover Ravi’s point though. He’s talking about conflicting in time, not in space. In this case, is a shortened occurrence the most intuitive? Would it be more intuitive to start both? They don’t conflict on the nodes they are running on. There’s no real reason the second occurrence couldn’t start on time. Now this doesn’t fit with our standing reservation framework. This would cause huge problems for us. I’m not suggesting we do it. I’m just bringing it up as an alternative to what the user might think.
I read through the use cases and acceptance criteria of PP-662 and it doesn’t talk about this. You are right, the PMs will have to extend the use case to include this.