Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update electron statuses for SlurmExecutor #39

Open
2 tasks
kessler-frost opened this issue Sep 16, 2022 · 1 comment
Open
2 tasks

Update electron statuses for SlurmExecutor #39

kessler-frost opened this issue Sep 16, 2022 · 1 comment

Comments

@kessler-frost
Copy link
Member

kessler-frost commented Sep 16, 2022

Once separation of workflow and electron statuses is done, the electron level statuses need to be updated to accommodate executor dependent statuses. In this case the following status definitions will be updated:

  • REGISTERING - Connection established to the remote machine and files are being transferred, slurm script also submitted

  • PENDING_BACKEND - Task is in the PENDING state in the slurm database

  • STARTING - Task is in the CONFIGURING state in the slurm database

  • RUNNING - Task is in the RUNNING state in the slurm database

  • COMPLETING - Task is in the COMPLETING state in the slurm database, result files are being retrieved, temporary files are being deleted

The classes for these statuses will need to be created similar to status classes defined in covalent/_shared_files/statuses.py. Then, in order to save the status, one can do:

...

status_store = task_metadata["status_store"]
status_store.save(CustomStatus())

...

This will propagate the status updation to the DB.

Acceptance Criteria:

  • Above mentioned statuses need to be updated inside the local executor
  • Tests need to be added to verify if those definitions are as expected
@Andrew-S-Rosen
Copy link
Contributor

Just adding on here that it would probably be good to have a timestamp or some indication of when the job starts running from the queued state, in addition to a more accurate description of the total elapsed runtime (since right now, the elapsed time starts ticking once the job script is submitted).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants