-
Notifications
You must be signed in to change notification settings - Fork 4
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
[Feature request]: Generic Cluster Config #342
Comments
All of that is very good, thanks. I wonder if we should even go to the route of having this configuration provide the ability to put a user-defined script for each cluster that is sourced at the start of the batch job (in case e.g LD_LIBRARY_PATH changes are made, or to change the I'm in favor of having it in this repo, but only slightly. Easier oversight. |
#191 wanted to link this issue to it as well. |
Draft solution to GH-342 with the ability to extend to other types of generic config/info in the future. Add `gempyor.info` module with exported function `get_cluster_info` which pulls and parses an information yaml into a pydantic model.
Draft solution to GH-342 with the ability to extend to other types of generic config/info in the future. Add `gempyor.info` module with exported function `get_cluster_info` which pulls and parses an information yaml into a pydantic model.
Draft solution to GH-342 with the ability to extend to other types of generic config/info in the future. Add `gempyor.info` module with exported function `get_cluster_info` which pulls and parses an information yaml into a pydantic model.
Label
good first issue, meta/workflow
Priority Label
low priority
Is your feature request related to a problem? Please describe.
Currently we have hard coded knowledge about rockfish and to a lesser extent longleaf throughout the repo. Which makes updating said info or adding new HPC environments painful. Has been described in other detail here: #329 (comment).
Is your feature request related to a new application, scenario round, pathogen? Please describe.
n/a
Describe the solution you'd like
Place config files, maybe yaml or something else, in a central place keyed on environment name. Where these should go is still an open question, viable options are:
I have a preference for (2) since this repository is already a bit bloated and updates to config would be small and need to be quickly done. Some information that would be helpful to know about each HPC environment in these config files would be:
Further work would be required to incorporate this info into our various scripts.
The text was updated successfully, but these errors were encountered: