I like the simplification (of passing a new extend parameter and) using the leading M in the name to convey the right information to the admin).
I have two (perhaps too much scope creep) suggestions which you can ignore, but here they are:
At the IFL level, how about making this new extend parameter specify the full name of the reservation? It’s only available for the operator/manager, so they would be responsible for ensuring no name conflicts (like they are today with queues). On the pbs_rsub side, one could either hard-code in something like “M” for now (and save any more extensions for later, or one could add an additional parameter that specifies the name of the reservation itself, e.g., -q (or if that’s taken already, maybe --resv_name). Since these reservations take precedence over other reservations, this would give admins a way to create all sorts of named reservations, not just for maintenance, but for other things too. (For even more extra credit, include recurring/standing reservations too.)
Rather than add a new command line parameter to pbs_rsub for nodes (and have that magically mean the reservation should forcibly succeed), introduce an explicit command line parameter, e.g., --force, (restricted to operator and manager only) that means make this reservation even if it conflicts with other reservations. Then, require the select & place specify the target for the reservation. In the initial version of the implementation, you could short-circuit the command to only accept lists of hosts and exclusive host, i.e., return an error unless the select/place matched the current use case of:
-lselect=host=n21+host=n22+host=n23+… and -lplace=exclhost
The main drawback here is that there’s not good syntax with select to ask for 1000s of hosts, so everyone would probably end up wrapping pbs_sub in these cases. The positive would be that the infrastructure would be ready to extend to arbitrary admin-forced reservations (at some future date) without changing syntax. It also means that if/when we design a better syntax for asking for 1000s of hosts, it can be plugged in here as well as in qsub, etc. (Again, at a future date).
Again, feel free to ignore – I do feel the design is good enough as is, and maintenance reservations will be really useful, so I don’t want to slow anything down with scope creep… but though I would share these ideas in case you (@vchlum) feel like they are a great fit and not too much more work.