mtitov
commented
11 months ago For one, I would like not to loose capabilities too quickly. It is one thing to not document or even discourage the mode, but another thing to unimplement it.
I actually thought that this is aligned with what we discussed - the main startup mode is from a batch job, and we allowed additionally to have a non-batch mode, but it should be a lightweight launcher (with further update such launcher will just submit a batch script with RP application in it)
Secondly, it is also aligned with our effort to switch to PSI/J completely
Also I don't see that this fixes anything really.
Not to confuse users with access_schema approach ON a machine (it did make sense for remote submission, but it is not for "local"), thus users don't need to think about "startup mode" and don't need to edit script no matter from where it is launched (from login node or from a batch job).
and additionally to cleanup all that schemas handling
PS.: the session should not need to know about batch system variables.
That check for variables could be moved to other place, I've put it into the Session module, since the extraction and processing of the config data was done there (but that method get_resource_config along with these variables can be moved into radical.pilot.utils space)
I would like to propose to clean up "schemas" and to have just 2 startup modes, which would be determined by RP automatically: non-batch (the current "local" schema, which later will be transformed into batch-launcher) and batch (default way to start RP apps).
Thus, we don't need to have "schemas" and we will have only one "schema" for non-batch mode, and when RP determines that it is a batch mode, then it overwrites corresponding attributes (
job_manager_endpoint,filesystem_endpoint). And we will remove all "remote submission" schemas that we don't support anymore.p.s. this is a partial PR to demonstrate the proposal, if we are all agree then we'll work on this PR to make it complete.