add UX documentation #61
Conversation
|
@ohtanim Thank you for your comments. Please check out the Direct Access section again -- it contains some ideas to cover some requirements and please do not hesitate to change it! |
|
|
||
| Slurm QPU resource definitions determine what physical resources can be used by slurm jobs. | ||
| User source code should be agnostic to specific backend instances and even backend types as far as possible. | ||
| This keeps source code portable while the QPU seletion criteria are part of the resource definition (which is considered configuration as opposed to source code). |
There was a problem hiding this comment.
| This keeps source code portable while the QPU seletion criteria are part of the resource definition (which is considered configuration as opposed to source code). | |
| This keeps source code portable while the QPU selection criteria are part of the resource definition (which is considered configuration as opposed to source code). |
| ### HPC admin scope | ||
|
|
||
| HPC administrators configure, what physical resources can be provided to slurm jobs. | ||
| Note sensitivethe config could contain sensitive information and m |
There was a problem hiding this comment.
| Note sensitivethe config could contain sensitive information and m | |
| Note that the config could contain sensitive information and m |
Not sure what @utzb might have wanted to continue writing at the end here..
| Note sensitivethe config could contain sensitive information and m | ||
|
|
||
| ``` | ||
| # slurm quauntum plugin configuration |
There was a problem hiding this comment.
| # slurm quauntum plugin configuration | |
| # slurm quantum plugin configuration |
| # DA backend | ||
| name=da-local-backend \ | ||
| url=https://da-endpoint.my-local.domain/ \ | ||
| da_crn=crn:v1:bluemix:public:quantum-computing:us-east:a/43aac17... \ | ||
| da_apikey_file=/root/da_apikey \ | ||
| s3_url=https://s3.my-local.domain/... \ | ||
| s3_accesstoken_file=/root/s3_accesstoken | ||
|
|
||
| # QRS backends | ||
| name=ibm_fez \ | ||
| type=qiskit-runtime-service-ibmcloud | ||
|
|
||
| name=ibm_marrakesh \ | ||
| type=qiskit-runtime-service-ibmcloud |
There was a problem hiding this comment.
I might just not have seen this config format before, but where does this get parsed and how will that system handle repeating keys (e.g. the name key being re-used without "sections")?
| #SBATCH --qpu=my_qpu_resource | ||
| #SBATCH --qpu-name=ibm_fez |
There was a problem hiding this comment.
Am I understanding correctly that the reason for setting --qpu=my_qpu_resource is that the application that gets srun below can then always refer to my_qpu_resource as the reference via which it then redirects to the actual resource (here: ibm_fez, specified via its name)? I.e. I could simply change ibm_fez to ibm_marrakesh and would not need to update the application code because it goes via the my_qpu_resource definition "redirect"?
| from qrmi import IBMDirectAccessSamplerV2 as SamplerV2 | ||
|
|
||
| # Generate transpiler target from backend configuration & properties | ||
| target = get_target(slurm_resource_name=“my_qpu_resource”) |
There was a problem hiding this comment.
Building on top of my previous comment, this still "couples" this application code to how the user configures sbatch. Can we not do something like:
target = get_target(slurm_resource_name=os.environ["SLURM_QPU_NAME"])where the SLURM_QPU_NAME environment variable gets automatically exported by our plugin?
See e.g. sbatch's output env variables.
More specifically, in the context of a spank plugin we might obtain SPANK_... (e.g. SPANK_QPU_NAME) according to https://slurm.schedmd.com/spank.html
Functions are also available from within the SPANK plugins to establish environment variables to be exported to the Slurm PrologSlurmctld, Prolog, Epilog and EpilogSlurmctld programs (the so-called job control environment). The name of environment variables established by these calls will be prepended with the string SPANK_ in order to avoid any security implications of arbitrary environment variable control. (After all, the job control scripts do run as root or the Slurm user.).
There was a problem hiding this comment.
If we would implement something like the above, the HPC user interface could be simplified down to a single --qpu-... specifier and would ensure that users don't need to look up the correct redirect name for pre-built applications (e.g.). It would also ensure some consistency across applications.
I am not sure how this plays out for multi-QPU jobs though... but I also do not see that laid out for the current proposal either..
| Access credentials should not visible to HPC users or other non-privileged users on the system. | ||
| Therefore, sensitive data is put in separate files which can be access protected accordingly. | ||
|
|
||
| Note that all users share the same access and hence need appropriate user vetting before getting access to quantum resources. |
There was a problem hiding this comment.
- Does that mean that per-user/per-group quota is then fully off-loaded to be tracked by the HPC admins? (to be clear, I am fine with that, if so)
- What does this imply for job monitoring capabilities? I.e. when querying job information from the DA API, who will be in charge of filtering the data down to the correct user/group?
Description of Change
Move UX (admin experience, user experience, application aspects) to own document, explain concepts better.
Checklist ✅
Ticket