PP-919: Add the abilty to stat all reservations from a remote server

Hi,

This is to inform the community about an interface change being made to the pbs_rstat command. I’m adding a new option @<server host> to pbs_rstat so that one can stat all reservations from a PBS server remotely.

Here’s the design document:
https://pbspro.atlassian.net/wiki/spaces/PD/pages/59047944/PP-919+Add+the+abilty+to+stat+all+reservations+from+a+remote+server

and here’s the JIRA ticket:
https://pbspro.atlassian.net/browse/PP-919

Please provide feedback!

Thanks,
Ravi

Requesting feedback, it’s been almost 2 weeks since I floated this. Thanks!

@agrawalravi90: My biggest concern was that similar functionality exist for clients like qstat, and I can see that it does. I think this is a very intuitive extension to existing pbs_rstat behavior. I have no further comment at this time.

Thanks Mike! Yes, my intent was to add something similar to what exists in qstat.

Requesting feedback from other members, the EDD is tiny!

I am all for the change and the EDD looks good to me, but I actually think this is a bug rather than an RFE and so may not actually need an EDD. The pbs_rstat man page says:

   Reservations at a server other than the default server:
   Specify the remote server's name using @remote_server.
   For an advance reservation:
       [R]sequence_number[.server_name][@remote_server]
   For a standing reservation:
       [S]sequence_number[.server_name][@remote_server]

Though I suppose one could read that second line both ways, either as an explicit declaration that you can use @remote_server by itself, OR as just a preface to the two scenarios that follow that include the sequence_number.

The current description does not indicate that @remote_server may be used as a standalone parameter, but as part of referencing a specific reservation. IMHO, it should remain an RFE with the accompanying EDD.

We will probably need a new line in the usage description: pbs_rstat [@remote_server]

I don’t mind fixing this as a bug and editing the document to clarify things, but, as Mike pointed out, there seems to be enough ambiguity in the language in the doc that it might be better to do this as a feature so that people are better aware of the existence of this feature. What do you think @scc?

RFE is fine, no problem, thanks.