Ah, that makes sense, thanks for clarifying Mike.
Sorry for the late breaking questions months after I gave a thumbs up, but I just re-read the EDD and these popped into my mind:
The EDD says that execution hooks will have read and write access to the m flag custom resources. Would any value change to the resource be propagated back to the server and reflected in qstat (etc.)?
How will an r flag resource that a “user = pbsuser” hook tries to alter a value of fail? Will the hook fail on the mom end, or will the mom hook carry on and the server will not allow the request to change?
Will the behaviors in questions 1 and/or 2 depend on whether or not the event was accepted or rejected?
EDIT: I retract question 4), which was “The EDD says that the m flag can be used with i flag resources. Will an i flag resource and value be visible in a mom hook if the hook’s “user” attribute is set to “pbsuser”?”. I am assuming the answer is something like “yes, the i flag resource will be visible to all mom hooks, the hook writer (root) should be careful not to expose the existence/value of the resource to maintain invisibility”.
These are good points. I need to add them to the design document. Below are the answers:
- Yes, any change done at hook level will propagate back to the server and should be reflected in qstat.
- If a resource with “r” flag is updated at the hook, it would make sense to error out at the MoM level itself instead of carrying it back to the server. Isn’t it?
- Yes, it will very much depend on if the hook accepted or rejected. Committing the changes done by a hook which was rejected might not make sense. What do you think?
- I agree with your answer. Hook writer should be careful on how he handles resources with “i” flag.
Hi Ashwath, thanks for the info. Yes I think it makes sense to error out at the mom level if a user hook tries to alter a read only attribute. Again, the hook writer should be careful
For 3., yes, the changes being passed to the server level should only happen upon accept (which would of course not happen if errors like read-only resources being modified by user hooks are caught at the mom level).
Overall looks good to me Ashwath. Thanks!