Conversation
…d out debug statements.
…nd list_queues functions
…hat use equivalent functions in status.py.
| raise S3MError(f'GET from {status_url} failed - {response.reason} ({response.status_code})') | ||
|
|
||
| def get_queue_status(self, queue_name : str) -> Tuple[bool, str]: | ||
| def get_system_status(self) -> Tuple[bool, dict]: |
There was a problem hiding this comment.
we should ideally pivot away from returning raw values like a Tuple of system status parts. This requires users to write something like
ok, status = client.get_system_status()
which is pretty unnatural in Py.
What I believe we should do instead is have a Python object that encompasses information about system status. Like a dataclass that includes a pointer to an enum for System state (including all the possible types like "OPERATIONAL", "DOWNGRADED", etc.).
from dataclasses import dataclass
@DataClass
class SystemStatus:
name: str
description: str
state: SystemState
upcoming_downtimes: ...
...
And then that SystemStatus object is returned (for example. Of course we can adjust the specific names / payloads / etc.)
| names : str = "" | ||
|
|
||
| names = [] | ||
| debug_msg = f'DEBUG: Slurm Queues on {self._cluster_name} - ' |
There was a problem hiding this comment.
The SDK probably shouldn't print, but pack the debug info into a returnable Python object.
| info = json.dumps(job_info, indent=4) | ||
| return True, info | ||
|
|
||
| return True, job_info |
There was a problem hiding this comment.
Same goes here, we should architect this to be some sort of JobInfo python object that contains ENUMs for all the enumeratable Python fields (like job status can only be the SLURM job statuses of RUNNING, COMPLETED, FAILED, etc. You can see the full list (including the less common types) here:
https://slurm.schedmd.com/job_state_codes.html
| @@ -49,8 +49,6 @@ def shutdown(service : StreamingService, cluster : str): | |||
|
|
|||
There was a problem hiding this comment.
Can we move these test files to the tests folder? These really don't serve a user-facing purpose as the CLI is a separate entity from the SDK (for now; you can chat with AJ about it if you're interested). But they can be useful for debugging. We can have a longer conversation about removing them entirely.
This pull request is intended to do a few things:
compute.pyand into its own python file.