Closed victorsndvg closed 5 years ago
If this feature is finally implemented, I think it deprecates the bootstrap
and revert
deployment steps.
E.g:
# boostrap_job happens in the login node
boostrap_job:
type: hpc.nodes.job
properties:
job_options:
type: 'SHELL'
command: 'scripts/bootstrap.sh'
relationships:
- type: job_contained_in_hpc
target: ft2_node
# parallel_job happens in compute nodes
parallel_job:
type: hpc.nodes.job
...
relationships:
- type: job_contained_in_hpc
target: ft2_node
- type: job_depends_on
target: bootstrap_job
# revert_job happens in the login node
revert_job:
type: hpc.nodes.job
properties:
job_options:
type: 'SHELL'
command: 'scripts/revert.sh'
relationships:
- type: job_contained_in_hpc
target: ft2_node
- type: job_depends_on
target: parallel_job
to think ... :thinking:
Hi @emepetres , any news on this?
@victorsndvg not yet sorry, still working on the inputs & data management. I'll be doing some changes on the orchestrator between today and tomorrow, I'll implement the feature then :)
Great, thanks @emepetres !
Hi,
as I was diving a little on your code, here I come with an extended suggestion. SHELL job type could be interesting to perform shell commands inside a workflow (e.g. some actions in a login node).
But I think it could be also interesting to have the None
WorkloadManager. I mean, to be able to interact with a machine with a ssh server but not a resouces manager, sending shell commands to a machine.
What do you think?
I've seen that there are, at least, 2 job types,
SBATCH
andSRUN
. I think it could be useful to have a newSHELL
type for running shell commands in a login node.Some use cases in which this
SHELL
type could be useful:SRUN
orSBATCH
job)SHELL
job)SRUN
orSBATCH
job)What do you think?